Re: Possible Idea with filesystem buffering.

Tommi Kyntola (kynde@ts.ray.fi)
Tue, 22 Jan 2002 12:09:32 +0200 (EET)


On Mon, 21 Jan 2002, Andreas Dilger wrote:
> On Jan 21, 2002 16:53 -0500, Chris Mason wrote:
> > On Monday, January 21, 2002 11:41:44 PM +0300 Hans Reiser wrote:
> > > If you think that VM should tell the FS when it has too many pages, does
> > > that mean that the VM understands that a particular page in the subcache
> > > has not been accessed recently enough? Is that the pivot point of our
> > > disagreement?
> >
> > Pretty much. I don't think the VM should say 'you have too many pages', I
> > think it should say 'free this page'.
>
> As above, it should have the capability to do both, depending on the
> circumstances. The FS can obviously make better judgements locally about
> what to write under normal circumstances, so it should be given the best
> chance to do so.
>
> The VM can make better _specific_ judgements when it needs to (e.g. free
> a DMA page or another specific page to allow a larger contiguous chunk
> of memory to be allocated), but in the cases where it just wants _some_
> page(s) to be freed, it should allow the FS to decide which one(s), if
> it cares.

Which is pretty close to what Anton said. It seems obvious that the VM
needs to use also a (hopefully rare-case) write_page where FS
should comply, wether it's suboptimal or not for that particular FS.

But wouldn't Anton's suggestion about having a sperate (hopefully more
common case) write_some_page that'd give some leash to FS developers to
optimize their page releasing based on their own demands ?

It'd atleast allow centralized VM and keeping the other filesystems
intact.

-- 
  Tommi "Kynde" Kyntola      
     /* A man alone in the forest talking to himself and 
        no women around to hear him. Is he still wrong?  */

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/