Re: CVS commit: src/sys/fs/puffs

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> wrote:
> 
>> > Sure ioflush do not directly free memory, but vnodes' dirty page use
>> > memory, don't they? If ioflush stops working, is pageadaemon able to
>> > pageout that kind of memory? 
>> pagedaemon flushes dirty pages by itself, yes.
> 
> So this is not a problem to get ioflush traped forever awaiting for a
> VOP_FSYNC completion? There must be some drawback, otherwise ioflush
> would be useless.

if it trapped forever, it's a bug and should be fixed.  my point was
that your change didn't fix the bug.  blocking ioflush is merely a symptom.

on the other hand, it needlessly introduced a limitation on what kernel
threads can do.  now we have vdrain_thread which i think can hit the
LW_SYSTEM assertion in puffs_vnop_fsync.

> 
>> a possible solution would be local page recycling.  ie. reserve some pages
>> and put them onto a page queue dedicated for a given set of processes
>> so that pages can be recycled in the set independently from the global queue.
> 
> But we do not know how much memory the userland fileserver is going to
> require. We can have some reserves, but we must be ready to kill pigs if
> too much memory is retained by the fileserver. HEAD does it, but
> netbsd-5 prefers to hang.

you don't need to know how much memory the server will use.
when the server runs out of the reserved set of pages, you can reuse
pages in the set.

YAMAMOTO Takashi

> 
> -- 
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu%netbsd.org@localhost