From: Christoph Lameter <cl@linux-foundation.org> To: Tejun Heo <tj@kernel.org> Cc: Nick Piggin <npiggin@suse.de>, Tony Luck <tony.luck@intel.com>, Fenghua Yu <fenghua.yu@intel.com>, linux-ia64 <linux-ia64@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Date: Mon, 28 Sep 2009 11:12:10 -0400 (EDT) [thread overview] Message-ID: <alpine.DEB.1.10.0909281104060.12252@gentwo.org> (raw) In-Reply-To: <4ABB2FE3.40608@kernel.org> On Thu, 24 Sep 2009, Tejun Heo wrote: > percpu implementation on ia64 has always been like that. The problem > with the alternate mapping is that you can't take the pointer to it as > it would mean different thing depending on which processor you're on > and the overall generic percpu implementation expects unique addresses > from percpu access macros. The cpu ops patchset uses per cpu addresses that are not relocated to a certain processor. The relocation is implicit in these instructions and must be implicit so these operations can be processor atomic. > ia64 currently has been and is the only arch which uses virtual percpu > mapping. The one biggest benefit would be accesses to the > local_per_cpu_offset. Whether it's beneficial enough to justify the > complexity, I frankly don't know. Its not worth working on given the state of IA64. I talked to Tony at the Plumbers conference. It may be beneficial to drop the virtual percpu mapping entirely because that would increase the number of TLB entries available. > Andrew once also suggested taking advantage of those overlapping > virtual mappings for local percpu accesses. If the generic code > followed such design, ia64's virtual mappings would definitely be more > useful, but that means we would need aliased mappings for percpu areas > and addresses will be different for local and remote accesses. Also, > getting it right on machines with virtually mapped caches would be > very painful. Given that %gs/fs offesetting is quite efficient on > x86, I don't think changing the generic mechanism is worthwhile. There is no problem with using unrelocated percpu addresses as an "address" for the cpu ops. The IA64 "virtual" addresses are a stand in for the segment registers on IA64. > So, it would be great if we can find a better way to offset addresses > on ia64. If not, nothing improves or deteriorates performance-wise > with the new implementation. Dropping the use of the special mapping over time may be the easiest way to go for IA64. percpu RMW ops like this_cpu_add are not possible with IA64 since no lightweight primitives exist. We could only avoid the calculation of the per cpu variables address. Would allow assignment and access to be atomic but not the RMW instruction. So it would not be a full per cpu ops implementation anyways.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux-foundation.org> To: Tejun Heo <tj@kernel.org> Cc: Nick Piggin <npiggin@suse.de>, Tony Luck <tony.luck@intel.com>, Fenghua Yu <fenghua.yu@intel.com>, linux-ia64 <linux-ia64@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu Date: Mon, 28 Sep 2009 15:12:10 +0000 [thread overview] Message-ID: <alpine.DEB.1.10.0909281104060.12252@gentwo.org> (raw) In-Reply-To: <4ABB2FE3.40608@kernel.org> On Thu, 24 Sep 2009, Tejun Heo wrote: > percpu implementation on ia64 has always been like that. The problem > with the alternate mapping is that you can't take the pointer to it as > it would mean different thing depending on which processor you're on > and the overall generic percpu implementation expects unique addresses > from percpu access macros. The cpu ops patchset uses per cpu addresses that are not relocated to a certain processor. The relocation is implicit in these instructions and must be implicit so these operations can be processor atomic. > ia64 currently has been and is the only arch which uses virtual percpu > mapping. The one biggest benefit would be accesses to the > local_per_cpu_offset. Whether it's beneficial enough to justify the > complexity, I frankly don't know. Its not worth working on given the state of IA64. I talked to Tony at the Plumbers conference. It may be beneficial to drop the virtual percpu mapping entirely because that would increase the number of TLB entries available. > Andrew once also suggested taking advantage of those overlapping > virtual mappings for local percpu accesses. If the generic code > followed such design, ia64's virtual mappings would definitely be more > useful, but that means we would need aliased mappings for percpu areas > and addresses will be different for local and remote accesses. Also, > getting it right on machines with virtually mapped caches would be > very painful. Given that %gs/fs offesetting is quite efficient on > x86, I don't think changing the generic mechanism is worthwhile. There is no problem with using unrelocated percpu addresses as an "address" for the cpu ops. The IA64 "virtual" addresses are a stand in for the segment registers on IA64. > So, it would be great if we can find a better way to offset addresses > on ia64. If not, nothing improves or deteriorates performance-wise > with the new implementation. Dropping the use of the special mapping over time may be the easiest way to go for IA64. percpu RMW ops like this_cpu_add are not possible with IA64 since no lightweight primitives exist. We could only avoid the calculation of the per cpu variables address. Would allow assignment and access to be atomic but not the RMW instruction. So it would not be a full per cpu ops implementation anyways.
next prev parent reply other threads:[~2009-09-28 15:16 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-09-22 7:40 [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one Tejun Heo 2009-09-22 7:40 ` Tejun Heo 2009-09-22 7:40 ` [PATCH 1/4] vmalloc: rename local variables vmalloc_start and vmalloc_end Tejun Heo 2009-09-22 7:40 ` Tejun Heo 2009-09-22 22:52 ` Christoph Lameter 2009-09-22 22:52 ` [PATCH 1/4] vmalloc: rename local variables vmalloc_start and Christoph Lameter 2009-09-23 2:08 ` [PATCH 1/4] vmalloc: rename local variables vmalloc_start and vmalloc_end Tejun Heo 2009-09-23 2:08 ` [PATCH 1/4] vmalloc: rename local variables vmalloc_start and Tejun Heo 2009-09-22 7:40 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-22 7:40 ` Tejun Heo 2009-09-22 22:59 ` Christoph Lameter 2009-09-22 22:59 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu Christoph Lameter 2009-09-23 2:11 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-23 2:11 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas Tejun Heo 2009-09-23 13:44 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Christoph Lameter 2009-09-23 13:44 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu Christoph Lameter 2009-09-23 14:01 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-23 14:01 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas Tejun Heo 2009-09-23 17:17 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Christoph Lameter 2009-09-23 17:17 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu Christoph Lameter 2009-09-23 22:03 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-23 22:03 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas Tejun Heo 2009-09-24 7:36 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Christoph Lameter 2009-09-24 7:36 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu Christoph Lameter 2009-09-24 8:37 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-24 8:37 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu areas Tejun Heo 2009-09-28 15:12 ` Christoph Lameter [this message] 2009-09-28 15:12 ` [PATCH 2/4] ia64: allocate percpu area for cpu0 like percpu Christoph Lameter 2009-09-22 7:40 ` [PATCH 3/4] ia64: convert to dynamic percpu allocator Tejun Heo 2009-09-22 7:40 ` Tejun Heo 2009-09-22 7:40 ` [PATCH 4/4] percpu: kill legacy " Tejun Heo 2009-09-22 7:40 ` Tejun Heo 2009-09-22 8:16 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one Ingo Molnar 2009-09-22 8:16 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic Ingo Molnar 2009-09-22 20:49 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one Luck, Tony 2009-09-22 20:49 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic Luck, Tony 2009-09-22 21:10 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one Luck, Tony 2009-09-22 21:10 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic Luck, Tony 2009-09-22 21:24 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one Luck, Tony 2009-09-22 21:24 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic Luck, Tony 2009-09-22 21:50 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one Tejun Heo 2009-09-22 21:50 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu Tejun Heo 2009-09-23 5:06 [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Tejun Heo 2009-09-23 5:06 ` Tejun Heo 2009-09-23 5:06 ` [PATCH 1/5] ia64: don't alias VMALLOC_END to vmalloc_end Tejun Heo 2009-09-23 5:06 ` Tejun Heo 2009-09-23 5:06 ` [PATCH 2/5] ia64: initialize cpu maps early Tejun Heo 2009-09-23 5:06 ` Tejun Heo 2009-09-23 5:06 ` [PATCH 3/5] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-23 5:06 ` Tejun Heo 2009-09-23 5:06 ` [PATCH 4/5] ia64: convert to dynamic percpu allocator Tejun Heo 2009-09-23 5:06 ` Tejun Heo 2009-09-23 5:06 ` [PATCH 5/5] percpu: kill legacy " Tejun Heo 2009-09-23 5:06 ` Tejun Heo 2009-09-23 11:10 ` Rusty Russell 2009-09-23 11:22 ` Rusty Russell 2009-09-29 0:25 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Tejun Heo 2009-09-29 0:25 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu Tejun Heo 2009-09-30 20:32 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Luck, Tony 2009-09-30 20:32 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic Luck, Tony 2009-09-30 20:47 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Christoph Lameter 2009-09-30 20:47 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu Christoph Lameter 2009-09-30 22:05 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Luck, Tony 2009-09-30 22:05 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic Luck, Tony 2009-09-30 23:06 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Peter Chubb 2009-09-30 23:06 ` Peter Chubb 2009-09-30 23:49 ` Christoph Lameter 2009-09-30 23:49 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu Christoph Lameter 2009-09-30 1:24 ` [PATCH REPOST 3/5] ia64: allocate percpu area for cpu0 like percpu areas for other cpus Tejun Heo 2009-09-30 1:24 ` [PATCH REPOST 3/5] ia64: allocate percpu area for cpu0 like percpu Tejun Heo 2009-10-02 5:11 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu and drop the old one, take#2 Tejun Heo 2009-10-02 5:11 ` [PATCHSET percpu#for-next] percpu: convert ia64 to dynamic percpu Tejun Heo
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=alpine.DEB.1.10.0909281104060.12252@gentwo.org \ --to=cl@linux-foundation.org \ --cc=fenghua.yu@intel.com \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=npiggin@suse.de \ --cc=rusty@rustcorp.com.au \ --cc=tj@kernel.org \ --cc=tony.luck@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: linkBe 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.