public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: hugh@veritas.com
Cc: wli@holomorphy.com, linux-kernel@vger.kernel.org,
	trivial@rustcorp.com.au
Subject: Re: remove mixture of non-atomic operations with page->flags which requires atomic operations to access
Date: Mon, 03 Jun 2002 02:12:36 -0700 (PDT)	[thread overview]
Message-ID: <20020603.021236.122031184.davem@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0206031051370.10595-100000@localhost.localdomain>

   From: Hugh Dickins <hugh@veritas.com>
   Date: Mon, 3 Jun 2002 11:14:43 +0100 (BST)

   On Sun, 2 Jun 2002, William Lee Irwin III wrote:
   > 
   >  	ClearPageDirty(page);
   > -	page->flags &= ~(1<<PG_referenced);
   > +	ClearPageUptodate(page);
   > +	ClearPageSlab(page);
   > +	ClearPageNosave(page);
   > +	ClearPageChecked(page);
   
   Don't all those atomic volatile bitops slow down a hotpath for no real
   gain?  I'm all for clearing all possible flag bits at that point, but
   would prefer just one mask myself.  But given all the preceding tests,
   and the ClearPageDirty, perhaps I'm foolish to question your additions.
   
   And wasn't it originally clearing the referenced bit, now leaving it?

Furthermore, when this code runs there should be no way for any
part of the kernel to reference the page in a way that cares
about these flag bits.

So if anything, we should be doing _ALL_ of the flag bitsops
non-atomically.

  reply	other threads:[~2002-06-03 10:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-02 22:44 remove mixture of non-atomic operations with page->flags which requires atomic operations to access William Lee Irwin III
2002-06-03 10:14 ` Hugh Dickins
2002-06-03  9:12   ` David S. Miller [this message]
2002-06-03 10:28   ` William Lee Irwin III
2002-06-03  9:27     ` David S. Miller
2002-06-03 11:00       ` William Lee Irwin III
2002-06-03 10:00         ` David S. Miller
2002-06-03 11:07           ` William Lee Irwin III

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=20020603.021236.122031184.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trivial@rustcorp.com.au \
    --cc=wli@holomorphy.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