svn commit: r233072 - projects/nand/sys/kern

[Konstantin Belousov]

On Mon, May 14, 2012 at 03:05:09PM +0200, Grzegorz Bernacki wrote:
> On 05/11/12 17:48, Mateusz Guzik wrote:
> >On Fri, May 11, 2012 at 01:46:48PM +0300, Konstantin Belousov wrote:
> >>On Thu, May 10, 2012 at 06:45:19PM +0200, Mateusz Guzik wrote:
> >>>http://people.freebsd.org/~raj/patches/misc/vfs_highdirtybuf.diff
> >>>
> >>>callbacks are expected to increase flushed counter if they happend to
> >>>flush some buffers.
> >>I do not think this is right. You need to call a routine when getnewblk()
> >>is unable to find a buffer to recycle.
> >>
> >>As I understand, in your situation with lot of managed buffers, the dirty
> >>queue could be just empty.
> >
> >I don't think I follow. Is your concern that with a lot of managed buffers 
> >and
> >empty dirty queue nothing can be recycled? Or that managed buffers
> >affect calls to buf_do_flush?
> >
> >I presume you talk about the code below the following:
> >         /*
> >          * If we exhausted our list, sleep as appropriate.  We may have to
> >          * wakeup various daemons and write out some dirty buffers.
> >          *
> >          * Generally we are sleeping due to insufficient buffer space.
> >          */
> >
> >         if (bp == NULL) {
> >
> >Conditions that cause bufdaemon weakups/buf_do_flush calls seem to be
> >not dependent on buffers being managed or not.
> >
> >buf_do_flush with our change always calls registered callbacks and the
> >callback that we register calls code that knowns what nandfs managed
> >buffers are dirty and flushes those. Buffers from dirty queues (if any)
> >are flushed separately.
> >
> >If I'm wrong or misunderstood you, please elaborate on problem you have
> >in mind.
> >
> >>>
> >>>Example proof-of-concept (will be cleaned up) change for nandfs:
> >>>http://people.freebsd.org/~raj/patches/misc/nandfs_vfs_highdirtybuf.diff
> >>>
> >>>Does this look reasonable?
> >>>
> >
> 
> 
> Hi Kostik,
> 
> We would like to merge our code into HEAD. Please let us know if you 
> have any objection. We are still going to work on buf deamon changes, 
> but we would like to avoid delay on pushing our changes into HEAD.
> 
> As I understand we agreed that we can merge B_MANAGED change from:
> http://people.freebsd.org/~gber/patches/vfs_bio2.diff

Yes, I have no objections against vfs_bio2.diff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20120514/c2ae64db/attachment.pgp