public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Christoph Hellwig <hch@ns.caldera.de>
Cc: Ingo Molnar <mingo@elte.hu>, yodaiken <yodaiken@fsmlabs.com>,
	Martin Wirth <Martin.Wirth@dlr.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	torvalds <torvalds@transmet.com>, rml <rml@tech9.net>,
	nigel <nigel@nrg.org>
Subject: Re: [RFC] New locking primitive for 2.5
Date: Fri, 08 Feb 2002 10:41:18 -0800	[thread overview]
Message-ID: <3C641BCE.196E1A37@zip.com.au> (raw)
In-Reply-To: <Pine.LNX.4.33.0202072305480.2976-100000@localhost.localdomain> <200202081231.g18CV7e31341@ns.caldera.de>

Christoph Hellwig wrote:
> 
> In article <Pine.LNX.4.33.0202072305480.2976-100000@localhost.localdomain> you wrote:
> > i think one example *could* be to turn inode->i_sem into a combi-lock. Eg.
> > generic_file_llseek() could use the spin variant.
> 
> No.  i_sem should be split into a spinlock for short-time accessed
> fields that get written to even if the file content is only read (i.e.
> atime) and a read-write semaphore.

I don't see any strong reason for taking i_sem in the generic seek
functions.  The only thing we seem to need to protect in there
is the non-atomic access to 64-bit i_size on 32-bit platforms,
for which a spinlock is appropriate.

I'd be interested in hearing more details on the regression which
Ingo has seen due to the introduction of i_sem locking in llseek.
Not just for "I told you so" value, but for the body of knowledge :)

-

  parent reply	other threads:[~2002-02-08 18:42 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-07 15:38 [RFC] New locking primitive for 2.5 Martin Wirth
2002-02-07 18:04 ` Daniel Phillips
2002-02-07 18:06   ` Richard Gooch
2002-02-07 18:22 ` Christoph Hellwig
2002-02-07 19:33   ` Daniel Phillips
2002-02-07 19:55   ` Mark Frazer
2002-02-08 12:24   ` Denis Vlasenko
2002-02-07 18:40 ` Robert Love
2002-02-07 19:25   ` Andrew Morton
2002-02-07 19:51     ` Dave Hansen
2002-02-07 20:06       ` Andrew Morton
2002-02-07 20:11         ` Robert Love
2002-02-07 21:27     ` Ingo Molnar
2002-02-07 19:59       ` Andrew Morton
2002-02-08  8:20     ` Nigel Gamble
2002-02-08 17:06       ` Larry McVoy
2002-02-07 19:58   ` yodaiken
2002-02-07 20:08     ` Robert Love
2002-02-07 20:15       ` yodaiken
2002-02-07 20:20         ` Robert Love
2002-02-07 20:36           ` yodaiken
2002-02-07 20:57             ` Daniel Phillips
2002-02-07 21:00               ` yodaiken
2002-02-07 21:10                 ` Daniel Phillips
2002-02-07 20:49   ` Martin Wirth
2002-02-08  8:34   ` Martin Wirth
2002-02-08 18:28     ` Linus Torvalds
2002-02-08 18:12       ` Martin Wirth
2002-02-08 18:33         ` Alexander Viro
2002-02-08 20:02         ` Linus Torvalds
2002-02-08 18:54           ` Andrew Morton
2002-02-08 19:11             ` Linus Torvalds
2002-02-08 19:21               ` Alexander Viro
2002-02-08 19:36                 ` Robert Love
2002-02-09  0:18                   ` Alexander Viro
2002-02-08 21:23                 ` Ingo Molnar
2002-02-08 21:36                   ` Linus Torvalds
2002-02-08 20:04                     ` Jeff Garzik
2002-02-08 21:16                       ` Mike Fedyk
2002-02-09  0:09                         ` Alan Cox
2002-02-09  0:05                           ` Mike Fedyk
2002-02-08 21:40                       ` Benjamin Herrenschmidt
2002-02-09 19:32                         ` Linus Torvalds
2002-02-07 19:56 ` yodaiken
2002-02-07 22:09   ` Ingo Molnar
2002-02-07 20:31     ` yodaiken
2002-02-07 20:57       ` Andrew Morton
2002-02-07 21:02         ` yodaiken
2002-02-08 12:31     ` Christoph Hellwig
2002-02-08 16:51       ` Nigel Gamble
2002-02-08 18:41       ` Andrew Morton [this message]
2002-02-08 20:47         ` Ingo Molnar
2002-02-08 18:56           ` Alexander Viro
2002-02-08 20:59             ` Ingo Molnar
2002-02-08 19:10               ` Alexander Viro
2002-02-08 20:14       ` Anton Altaparmakov
2002-02-08 20:38         ` yodaiken
2002-02-08 21:55         ` Anton Altaparmakov
2002-02-08 12:47   ` Denis Vlasenko
2002-02-08 15:13     ` yodaiken
2002-02-08 19:22 ` Horst von Brand

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=3C641BCE.196E1A37@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=Martin.Wirth@dlr.de \
    --cc=hch@ns.caldera.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nigel@nrg.org \
    --cc=rml@tech9.net \
    --cc=torvalds@transmet.com \
    --cc=yodaiken@fsmlabs.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