All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Zarochentsev <zam@namesys.com>
To: reiserfs-dev@namesys.com
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: partial reiser4 review comments
Date: Fri, 4 Aug 2006 00:11:16 +0400	[thread overview]
Message-ID: <200608040011.16363.zam@namesys.com> (raw)
In-Reply-To: <20060803001741.4ee9ff72.akpm@osdl.org>

> I'm only partway through this, but let me unload my observations thus
> far. I still need to find a chunk of time for a file-by-file
> walkthrough and it's unobvious where that chunk will come from at
> present :(
>
>
> reiser4 as found in 2.6.18-rc2-mm1.
>
> - set_page_dirty_internal() pokes around in VFS internals.  Use
>   __set_page_dirty_no_buffers() or create a new library function in
>   mm/page-writeback.c.
>
>   In particular, it gets the radix-tree dirty tagging out of sync.
>
> - running igrab() in the writepage() path is really going to hammer
>   inode_lock.  Something else will need to be done here.
>
> - The preferred way of solving the above would be to mark the page as
>   PageWriteback() with set_page_writeback() prior to unlocking it. 
> That'll pin the page and the inode.  It does require that the page
> actually get written later on.  If we cannot do that then more
> thought is needed.
>
> - wbq.sem should be using a completion for the "wait until entd
> finishes", not a semaphore.  Because there's a teeny theoretical race
> when using semaphores this way which completions were designed to
> avoid.  (The waker can still be playing with the semaphore when it
> has gone out of scope on the wakee's stack).
>
> - write_page_by_ent(): the "spin until entd thread" thing is gross.

that spinlock is especially against the "teeny theoretical race...".  
good if completion will allow us to remove it.

>
>   This function is really lock-intensive.


Thanks,
Alex.


      parent reply	other threads:[~2006-08-03 20:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03  7:17 partial reiser4 review comments Andrew Morton
2006-08-03 14:26 ` Christoph Hellwig
2006-08-06 14:38   ` Alexander Zarochentsev
2006-08-09  8:59     ` Christoph Hellwig
2006-08-09  9:18       ` Hans Reiser
2006-08-10 18:31         ` Nate Diller
2006-08-11 17:55           ` Hans Reiser
2006-08-11 23:02             ` Nate Diller
2006-08-03 20:11 ` Alexander Zarochentsev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200608040011.16363.zam@namesys.com \
    --to=zam@namesys.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-dev@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.