All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC 0/4]x86: allocate up to 32 tlb invalidate vectors
Date: Mon, 15 Nov 2010 09:53:55 -0800	[thread overview]
Message-ID: <4CE173B3.9000603@zytor.com> (raw)
In-Reply-To: <1289829765.14740.2.camel@sli10-conroe>

On 11/15/2010 06:02 AM, Shaohua Li wrote:
> On Wed, 2010-11-03 at 14:44 +0800, Shaohua Li wrote:
>> Hi,
>> In workload with heavy page reclaim, flush_tlb_page() is frequently
>> used. We currently have 8 vectors for tlb flush, which is fine for small
>> machines. But for big machines with a lot of CPUs, the 8 vectors are
>> shared by all CPUs and we need lock to protect them. This will cause a
>> lot of lock contentions. please see the patch 3 for detailed number of
>> the lock contention.
>> Andi Kleen suggests we can use 32 vectors for tlb flush, which should be
>> fine for even 8 socket machines. Test shows this reduces lock contention
>> dramatically (see patch 3 for number).
>> One might argue if this will waste too many vectors and leave less
>> vectors for devices. This could be a problem. But even we use 32
>> vectors, we still leave 78 vectors for devices. And we now have per-cpu
>> vector, vector isn't scarce any more, but I'm open if anybody has
>> objections.
>>
> Hi Ingo & hpa, any comments about this series?
> 

Hi Shaohua,

It looks good... I need to do a more thorough review and put it in; I
just have been consumed a bit too much by a certain internal project.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


      reply	other threads:[~2010-11-15 17:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03  6:44 [RFC 0/4]x86: allocate up to 32 tlb invalidate vectors Shaohua Li
2010-11-15 14:02 ` Shaohua Li
2010-11-15 17:53   ` H. Peter Anvin [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=4CE173B3.9000603@zytor.com \
    --to=hpa@zytor.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=shaohua.li@intel.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.