Re: arca-vm-8 [Re: [patch] arca-vm-6, killed kswapd [Re: [patch] new-vm , improvement , [Re: 2.2.0 Bug summary]]]

Eric W. Biederman
1999-01-08T03:43:33Z

>>>>> "LT" == Linus Torvalds <torvalds@transmeta.com> writes:

LT> On 6 Jan 1999, Eric W. Biederman wrote:
>>
>> 1) With your comments on PG_dirty/(what shrink_mmap should do) you
>> have worked out what needs to happen for the mapped in memory case,
>> and I haven't quite gotten there. Thank You.

LT> Note that it is not finalized. That's why I didn't write the code (which
LT> should be fairly simple), because it has some fairly subtle issues and
LT> thus becomes a 2.3.x thing, I very much suspect.

The code probably will be simple enough, but there are issues.
The complete issue for 2.3.x is dirty data in the page cache,
mapped shared pages are just a small subset.

This will be much more important for NFS, e2compr, and not
double buffering between the page cache and the buffer cache,
than for this case.

>> 2) I have tested using PG_dirty from shrink_mmap and it is a
>> performance problem because it loses all locality of reference,
>> and because it forces shrink_mmap into a dual role, of freeing and
>> writing pages, which need seperate tuning.

LT> Exactly. This is part of the complexity.

LT> The right solution (I _think_) is to conceptually always mark it PG_dirty
LT> in vmscan, and basically leave all the nasty cases to the filemap physical
LT> page scan. But in the simple cases (ie a swap-cached page that is only
LT> mapped by one process and doesn't have any other users), you'd start the
LT> IO "early".

This sounds good for the subset of the problem you are considering.

>From where I'm at something that allocates a streamlined buffer_head
to the diry pages, sounds even better. That and having a peridic
scan of the page tables that removes the dirty bit and marks the
pages dirty, before we need the pages to be clean.

LT> Basically, I think that the stuff we handle now with the swap-cache we do
LT> well on already, and we'd only really want to handle the shared memory
LT> case with PG_dirty. But I think this is a 2.3 issue, and I only added the
LT> comment (and the PG_dirty define) for now.

Thanks it does give some encouragement and some relief. There are enough
things to get shaken out, I am much more comfortable with early 2.3,
where we have time to convert things to a new way of doing things.

LT> It might be something good to test out, but I really don't want patches at
LT> this date (unless your patches also fix the above deadlock problem, which
LT> I can't see them doing ;)

Then I will proceed with my previous plan and see if I can get a fairly
complete set of patches ready for 2.3.early

Eric