public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox