RE: [PATCH] percpu: add optimized generic percpu accessors
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx>
- Subject: RE: [PATCH] percpu: add optimized generic percpu accessors
- From: "Luck, Tony" <tony.luck@xxxxxxxxx>
- Date: Wed, 28 Jan 2009 09:15:08 -0800
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: Rick Jones <rick.jones2@xxxxxx>, David Miller <davem@xxxxxxxxxxxxx>, "tj@xxxxxxxxxx" <tj@xxxxxxxxxx>, "rusty@xxxxxxxxxxxxxxx" <rusty@xxxxxxxxxxxxxxx>, "mingo@xxxxxxx" <mingo@xxxxxxx>, "herbert@xxxxxxxxxxxxxxxxxxx" <herbert@xxxxxxxxxxxxxxxxxxx>, "akpm@xxxxxxxxxxxxxxxxxxxx" <akpm@xxxxxxxxxxxxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "brgerst@xxxxxxxxx" <brgerst@xxxxxxxxx>, "ebiederm@xxxxxxxxxxxx" <ebiederm@xxxxxxxxxxxx>, "travis@xxxxxxx" <travis@xxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "steiner@xxxxxxx" <steiner@xxxxxxx>, "hugh@xxxxxxxxxxx" <hugh@xxxxxxxxxxx>, "netdev@xxxxxxxxxxxxxxx" <netdev@xxxxxxxxxxxxxxx>, "mathieu.desnoyers@xxxxxxxxxx" <mathieu.desnoyers@xxxxxxxxxx>, "linux-ia64@xxxxxxxxxxxxxxx" <linux-ia64@xxxxxxxxxxxxxxx>
- In-reply-to: <alpine.DEB.1.10.0901281146260.13825@xxxxxxxxx>
- List-id: <linux-ia64.vger.kernel.org>
- References: <200901271213.18605.rusty@xxxxxxxxxxxxxxx> <497E705B.5000302@xxxxxxxxxx> <alpine.DEB.1.10.0901271506580.3114@xxxxxxxxx> <20090127.134747.153565246.davem@xxxxxxxxxxxxx> <497F8F02.9000603@xxxxxx> <57C9024A16AD2D4C97DC78E552063EA35F317617@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.1.10.0901281146260.13825@xxxxxxxxx>
- Thread-index: AcmBasGfweyc+KCeQn6s7srqPjs15wAAHiIA
- Thread-topic: [PATCH] percpu: add optimized generic percpu accessors
> > Managing a larger space could be done ... but at the expense of making
> > the Alt-DTLB miss handler do a memory lookup to find the physical address
> > of the per-cpu page needed (assuming that we allocate a bunch of random
> > physical pages for use as per-cpu space rather than a single contiguous
> > block of physical memory).
>
> We cannot resize the area by using a single larger TLB entry?
Yes we could ... the catch is that the supported TLB page sizes go
up by multiples of 4. So if 64K is not enough the next stop is
at 256K, then 1M, then 4M, and so on.
That's why I asked when we know what total amount of per-cpu memory
is needed. CONFIG time or boot time is good, because allocating higher
order pages is easy at boot time. Arbitrary run time is bad because
we might have difficulty allocating a high order page for every cpu.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]