Re: bdflush flushing memory mapped pages.

[Andrew Morton]

Andre Hedrick <[e-mail]> wrote:
>
> 
> Funny you mention this point!
> 
> I just spent 30-45 minutes on the phone talking to Jens about this very
> issue.  Jens states he can map the model in to 2.5. and will give it a
> fling in a bit.  This issue is a must; however, I had given up on the idea
> until 2.7.  However, the issues he and I addressed, in combination to your
> request jive in sync.

noooo.....   This isn't going to happen.  There are many reasons.

Firstly, how can bdflush even know what pages to write?  The dirtiness of
these pages is recorded *only* in some processor's hardware pte cache and/or
the software pagetables.  Someone needs to go tell all the CPUs to writeback
their pte caches into the pagetables and then someone needs to walk the
pagetables propagating the pte dirty bit into the pageframes before we can
even start the I/O.

That's what msync does, in filemap_sync().

And even if bdflush did this automagically, it's the wrong thing to do
because the application could very well be repeatedly dirtying the pages. 
Very probably.  So we've just gone and done a ton of pointless I/O, over and
over.

You can view MAP_SHARED as an IPC mechanism which uses the filesystem
namespace for naming.  No way do these people want bdflush pointlessly
hammering the disk.

You can also view MAP_SHARED as a (strange) way of writing files out.  If you
want to do that then fine, but you need to tell the kernel when you've
finished, just like write() does.   You do that with msync.