>>>>> "chris" == Chris Mason <mason@suse.com> writes:
Hi
>> I have not read nor ReiserFS code nor ext3 code. Do you push all your
>> pages in the page cache?
chris> All my pinned memory is in the buffer cache right now.
Nice to hear that. I am also changing a bit *how* the memory is
reclaimed just now (shrink_mmap and similar).
>> If that is the case, I think that a call in
>> the address space operations is great. The problem is that I can't
>> see how do you will be able to free memory from an isolated page, I
>> assume that you need _quite a lot_ of context to decide which page you
>> can free.
>>
chris> It gets sticky, because it is unlikely the journal layers (of any FS) can
chris> free a huge amount of pinned memory on demand. We can commit old, async
chris> transactions (completed transcations that are fully in the log yet) right
chris> away, but we can't force the current transaction to end until all the
chris> writers are done.
chris> So, my memory pressure call back will probably ignore the page being sent
chris> in (aside from finding the inode/super associated with it) It will
chris> free what it can, and schedule a commit/flush of the current transaction
chris> as soon as possible.
If you would ignore the page that the address operations send you,
then I think that it would be better to use one method like the
shrink_[di]cache, where do_try_to_free_pages notifies your subsystem
that we are low on memory, and one priority. You then try to free
pages harder based on the priority argument. Notice that just know
shrink_[di]cache didn't return the number of pages that they have
liberated, but it is a good idea to return that number. Otherwise it
is imposible to balance the preassure of memory between the different
subsystems.
chris> Later on, it could be tuned to only try to flush the transactions
chris> associated with a given page, I can only guess right now on the results.
I think the same. This is 2.5 material anyway :)
Later, Juan.
-- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy- 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:25 EST