On 6 Jun 2000, Quintela Carreira Juan J. wrote:
> >>>>> "chris" == Chris Mason <mason@suse.com> writes:
>
>
> Hi
>
> chris> I'm not partial to how the actually memory pressure subsystem works, but I
> chris> do like the idea of putting it in the address space operations. It just
> chris> seems right, memory pressure goes against adress spaces.
>
> Chris, I think that you don't want to put that in the address space
> operations, the main reason is that you don't want your pages to stay
> in the main LRU queue, because you need to freed them in an specific
> order (not LRU at all). Then if shrink_mmap is not scanning your
> pages, it is better to use your own reclaim function, that would be
> called from do_try_to_free_pages (a la shrink_[di]cache way).
>
The goal isn't to make something perfect for the journaled filesystems, it
is a generic facility that also happens to work for the journaled
filesystems. So, I like the address space operations, mostly
because this is an operation on an address space ;-)
> chris> Plus, it allows more flexibility later on...the log really should be an
> chris> address space of its own, and the pressure should be applied against the
> chris> log, not the FS. Think of multiple filesystems to a log, or multiple
> chris> logs in a filesystem. Yes, these are ideas for 2.5 ;-)
>
> This reason _completely_ convinces me that you want something like one
> reclaim_cache function. Notice that otherwise you will be called more
> times that you want to be called. If you put your pages in the main
> LRU and you put a function in the address space, that function will be
> called each time that one of *your* pages is scaned. That means that
> if your function is called in one moment, and the next page also
> belongs to your address space, you are getting *too* much pressure.
>
The function can be a quick inline test that checks to see if a commit has
already been requested. So, it can go into the deeper, slower routine
only when that will gain something. If there are schedules during the
scanning, there is a good chance transactions will commit during the scan,
and future pressure will result in more free pages.
There are other ways to do this, and I'm more than willing to help code
them. If you want to make a case for the register cache functions, lets
take this offline.
thanks,
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:26 EST