Date: Mon, 10 Feb 2003 14:54:07 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org> Cc: Morten Rodal <morten@rodal.no>, phk@phk.freebsd.dk, David Schultz <dschultz@uclink.Berkeley.EDU>, arch@FreeBSD.ORG Subject: Re: Our lemming-syncer caught in the act. Message-ID: <200302102254.h1AMs7ra023931@apollo.backplane.com> References: <20030210091317.GD5165@HAL9000.homeunix.com> <37473.1044868995@critter.freebsd.dk> <20030210204523.GF12240@slurp.rodal.no> <20030210205443.GA88781@elvis.mu.org> <200302102225.h1AMPkTE023700@apollo.backplane.com> <20030210223904.GG88781@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:There are several good points in your mail, especially about performing
:partial fsyncs, however this doesn't really explain why 4.x is "ok" versus
:5.x having issues. The only explanation I can think of is that the syncer
:runs with giant for a long time but under 4.x only needs splbio() for short
:periods.
The syncer tends to block quite a bit under normal operation, so it
seems unlikely that Giant would be an issue unless the syncer is looping
without getting any work accomplished. *THIS* is possible, since we've
already had to hack the syncer considerably to prevent it from looping
on unflushable softupdates buffers. There could be new cases that have
not been addressed.
If I recall I have made one change in the last few months which might
be worth looking at.
dillon 2002/12/28 13:03:42 PST
Modified files:
sys/vm vm_object.c vm_pager.h vnode_pager.c
Log:
Allow the VM object flushing code to cluster. When the filesystem syncer
comes along and flushes a file which has been mmap()'d SHARED/RW, with
dirty pages, it was flushing the underlying VM object asynchronously,
resulting in thousands of 8K writes. With this change the VM Object flushing
code will cluster dirty pages in 64K blocks.
Note that until the low memory deadlock issue is reviewed, it is not safe
to allow the pageout daemon to use this feature. Forced pageouts still
use fs block size'd ops for the moment.
MFC after: 3 days
Revision Changes Path
1.250 +10 -3 src/sys/vm/vm_object.c
1.37 +4 -2 src/sys/vm/vm_pager.h
1.165 +8 -2 src/sys/vm/vnode_pager.c
But, as you can see, it is in -stable as well. I doubt the above could
be the cause.
Profiling the problem in action might give us some more clues.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200302102254.h1AMs7ra023931>