mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Jes Sorensen <jes@sgi.com>, Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [patch] reduce IPI noise due to /dev/cdrom open/close
Date: Mon,  3 Jul 2006 11:37:43 -0400 (EDT)	[thread overview]
Message-ID: <200607040516.k645GFTj014564@sullivan.realtime.net> (raw)
In-Reply-To: <yq0mzbqhfdp.fsf@jaguar.mkp.net>

On Mon Jul 03 2006 - 11:37:43 EST,  Jes Sorensen wrote:
> Certain applications cause a lot of IPI noise due to them constantly
> doing open/close on /dev/cdrom. hald is a particularly annoying case
> of this. However since every distribution insists on shipping it, it's
> one of those that are hard to get rid of :(
> 
> Anyway, this patch reduces the IPI noise by keeping a cpumask of CPUs
> which have items in the bh lru and only flushing on the relevant
> CPUs. On systems with larger CPU counts it's quite normal that only a
> few CPUs are actively doing block IO, so spewing IPIs everywhere to
> flush this is unnecessary.
> 

Ok we are optimizing for the low but not zero traffic case ... 


> + cpu = raw_smp_processor_id();
> + /* Test first to avoid cache lines bouncing around */
> + if (!cpu_isset(cpu, lru_in_use))
> + cpu_set(cpu, lru_in_use);

Being set when local array is filled, under local locking only, but its
a set_bit and ok.


> static void invalidate_bh_lrus(void)
> {
> - on_each_cpu(invalidate_bh_lru, NULL, 1, 1);
> + /*
> + * Need to hand down a copy of the mask or we wouldn't be run
> + * anywhere due to the original mask being cleared
> + */
> + cpumask_t mask = lru_in_use;
> + cpus_clear(lru_in_use);
> + schedule_on_each_cpu_mask(invalidate_bh_lru, NULL, mask);
> }


But that is totally racy!

Another cpu could set its bit between the assignment to mask and
the call to cpus_clear.

Which means we end up with cpus holding a bh in their lru but no
idea which ones.

Unfornately clearing the bit in the callback means we pass the cpu
mask around twice (once to clear, and later to set as we start
freeing bhs again).

Although that is probably not much worse than scanning other cpus'
per-cpu data for NULL (and I would probably just scan 8 pointers
rather than add another per-cpu something is cached flag).


I don't like the idea of invalidate_bdev (say due to openers going
to zero) running against one device causing a buffer to be left
artificially busy on another device, causing a page to be left
around.

If you want to cut down on the cache line passing, then putting
the cpu mask in the bdev (for "I have cached a bh on this bdev
sometime") might be useful.  You could even do a bdev specific
lru kill, but then we get into the next topic.


And now for the "what is that code doing?" part of this review:

 * The LRU management algorithm is dopey-but-simple.  Sorry.

Umm.. yes.

(but time for a new subject).

milton
[sorry for the whitespace munging]

  reply	other threads:[~2006-07-04  5:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-03 15:33 Jes Sorensen
2006-07-03 15:37 ` Milton Miller [this message]
2006-07-04  7:47   ` Jes Sorensen
2006-07-04  7:53     ` Arjan van de Ven
2006-07-04  8:12       ` Jes Sorensen
2006-07-04  8:23         ` Arjan van de Ven
2006-07-04  8:33           ` Jes Sorensen
2006-07-04 13:02         ` Helge Hafting
2006-07-04  8:42     ` Milton Miller
2006-07-04  8:59       ` Jes Sorensen
2006-07-04  9:30         ` Milton Miller
2006-07-03 15:37 ` [PATCH] simplfy bh_lru_install Milton Miller
2006-07-03 15:37   ` Milton Miller
2006-07-04  5:32 ` [patch] reduce IPI noise due to /dev/cdrom open/close Keith Owens
2006-07-04  6:41   ` Andrew Morton
2006-07-04  7:51     ` Jes Sorensen
2006-07-04  9:13     ` Milton Miller
2006-07-04 17:33     ` Nick Piggin
2006-07-05  7:30       ` Jes Sorensen
2006-07-05 18:26         ` Nick Piggin
2006-07-05  0:10     ` Paul Mackerras
2006-07-04  7:49   ` Jes Sorensen
2006-07-04  8:04     ` Andrew Morton

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=200607040516.k645GFTj014564@sullivan.realtime.net \
    --to=miltonm@bga.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®