[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multipage requests for GNU Mach 1,3
From: |
Neal H. Walfield |
Subject: |
Re: Multipage requests for GNU Mach 1,3 |
Date: |
Sun, 19 Dec 2004 12:57:23 +0000 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) |
> Yes, I've forgotten to talk about page outs :-) as you said,
> m_o_lock_request calls m_o_data_return sending
> multiple pages at once, but due to the libpager's API limitation,
> writting is done page by page:
>
> for (i = 0; i < npages; i++)
> if (!(omitdata & (1 << i)))
> pagerrs[i] = pager_write_page (p->upi,
> offset + (vm_page_size * i),
> data + (vm_page_size * i));
>
> Changing libpager's API, and working a little in translators, this issue
> can be easily solved. Also, I'll take a look at vm_pageout_page and
> vm_pageout_scan (I've done that before, but touching it makes Mach
> become some unstable, probably I was doing it the wrong way).
m_o_lock_request is not the common pageout path. It is a way for
memory managers to force Mach to return pages. Page outs normally
occur in vm_pageout_page when Mach returns pages to a memory manager
to write to backing store due to for instance memory pressure. This
latter scenario only ever returns a single page at a time and is the
far more important case to consider.
Anyways, we only ever check in one change at a time so first finish
the clustered page ins and then we can start to consider how this
change will look.
> > Mac OS X, which is based off of OSF's Mach, supports this in
> > memory_object_change_attributes [1]. I think it makes sense to be
> > compatible with their interface even it if means updating our API.
> >
>
> Fine, anyways, having multipage support requires API changes.
Yes. I am just suggesting that we not be gratuitously incompatible
with the extant interfaces.
> Yes, I changed libpager, ext2fs and isofs for testing pruposes. I've
> just uploaded the Hurd tree to Bee's CVS (*.mp are the modified
> directories).
>
> If you look at that code, you'll find some calls to *_direct functions,
> and that there are no memory allocations on file_page_read_multipage().
> As I said before, the code in CVS contains other changes, not only the
> ones realted to multipage requests. Those *_direct functions are a
> experimental change, which makes that the glue code inserts the
> requested pages directly to the pager's memory object.
>
> I think that I'll reimplement multipage support on a clean GNU Mach
> tree, to make changes progressive and easy to review.
I will look at the changes when you provide a patch. It doesn't need
to be a highly polished patch but something that I can easily browse
without lots of unrelated changes.
Thanks,
Neal