bug-hurd
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]