search for: percpu

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) - page-align the gdt - remove the pda and convert all pda usages into percpu variables...

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) - page-align the gdt - remove the pda and convert all pda usages into percpu variables...

On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote: > From: Kent Overstreet <kmo at daterainc.com> > > Percpu frontend for allocating ids. With percpu allocation (that works), > it's impossible to guarantee it will always be possible to allocate all > nr_tags - typically, some will be stuck on a remote percpu freelist > where the current job can't get to them. > > We do guarantee th...

On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote: > From: Kent Overstreet <kmo at daterainc.com> > > Percpu frontend for allocating ids. With percpu allocation (that works), > it's impossible to guarantee it will always be possible to allocate all > nr_tags - typically, some will be stuck on a remote percpu freelist > where the current job can't get to them. > > We do guarantee th...

From: Kent Overstreet <kmo at daterainc.com> Percpu frontend for allocating ids. With percpu allocation (that works), it's impossible to guarantee it will always be possible to allocate all nr_tags - typically, some will be stuck on a remote percpu freelist where the current job can't get to them. We do guarantee that it will always be poss...

On Tue, Aug 20, 2013 at 02:31:57PM -0700, Andrew Morton wrote: > On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote: > > + /* > > + * Bitmap of cpus that (may) have tags on their percpu freelists: > > + * steal_tags() uses this to decide when to steal tags, and which cpus > > + * to try stealing from. > > + * > > + * It's ok for a freelist to be empty when its bit is set - steal_tags() > > + * will just keep looking - but the bitmap _must_ be...

...some microbenchmark on powerpc system with or w/o the patch. On a 2-socket 160-thread SMT4 POWER9 system (not virtualized): 5.8.0-rc4 ========= Running locktest with spinlock [runtime = 10s, load = 1] Threads = 160, Min/Mean/Max = 77,665/90,153/106,895 Threads = 160, Total Rate = 1,441,759 op/s; Percpu Rate = 9,011 op/s Running locktest with rwlock [runtime = 10s, r% = 50%, load = 1] Threads = 160, Min/Mean/Max = 47,879/53,807/63,689 Threads = 160, Total Rate = 860,192 op/s; Percpu Rate = 5,376 op/s Running locktest with spinlock [runtime = 10s, load = 1] Threads = 80, Min/Mean/Max = 242,907/31...

...happily and silently do so even though it's clearly bogus: long long ret; asm ("movl $5, %0" : "=r" (ret)); $ clang -c -o q.o q.c -m32 $ gcc -c -o q.o q.c -m32 q.c: In function ‘foo’: q.c:6:1: warning: unsupported size for integer register --- arch/x86/include/asm/percpu.h | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h index ba3c523aaf16..3b0e413670e4 100644 --- a/arch/x86/include/asm/percpu.h +++ b/arch/x86/include/asm/percpu.h @@ -99,7 +99,7 @@ do { \ case 1:...

On Wed, 28 Aug 2013 12:55:17 -0700 Kent Overstreet <kmo at daterainc.com> wrote: > Fixup patch, addressing Andrew's review feedback: Looks reasonable. > lib/idr.c | 38 +++++++++++++++++++++----------------- I still don't think it should be in this file. You say that some as-yet-unmerged patches will tie the new code into the old ida code. But will it do it in a

Hi Jeremy, all, Sorry this took so long, spent last week in Japan at OSDL conf then netconf. After several false starts, I ended up with a very simple implementation, which clashes significantly with your work since then 8(. I've pushed the patches anyway, but it's going to be significant work for me to re-merge them, so I wanted your feedback first. The first patch simply changes

Hi Jeremy, all, Sorry this took so long, spent last week in Japan at OSDL conf then netconf. After several false starts, I ended up with a very simple implementation, which clashes significantly with your work since then 8(. I've pushed the patches anyway, but it's going to be significant work for me to re-merge them, so I wanted your feedback first. The first patch simply changes

On Wed, 28 Aug 2013 12:55:17 -0700 Kent Overstreet <kmo at daterainc.com> wrote: > Fixup patch, addressing Andrew's review feedback: Looks reasonable. > lib/idr.c | 38 +++++++++++++++++++++----------------- I still don't think it should be in this file. You say that some as-yet-unmerged patches will tie the new code into the old ida code. But will it do it in a

...00533d2f5f1355b8 # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp at intel.com> All error/warnings (new ones prefixed by >>): In file included from include/asm-generic/percpu.h:7:0, from arch/x86/include/asm/percpu.h:556, from arch/x86/include/asm/preempt.h:6, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/wait.h:9,...

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi folks, This is an updated series for adding tag pre-allocation support of target fabric descriptor memory, utilizing Kent's latest per-cpu ida bits here, along with Christoph Lameter's latest comments: [PATCH 04/10] idr: Percpu ida http://marc.info/?l=linux-kernel&m=137160026006974&w=2 The first patch is a standalone version of per-cpu-ida, seperate from the full idr rewrite from Kent that is still being discussed. Given that I have a number of other target items aside from this series that depend on this cod...

From: Nicholas Bellinger <nab at linux-iscsi.org> Hi folks, This is an updated series for adding tag pre-allocation support of target fabric descriptor memory, utilizing Kent's latest per-cpu ida bits here, along with Christoph Lameter's latest comments: [PATCH 04/10] idr: Percpu ida http://marc.info/?l=linux-kernel&m=137160026006974&w=2 The first patch is a standalone version of per-cpu-ida, seperate from the full idr rewrite from Kent that is still being discussed. Given that I have a number of other target items aside from this series that depend on this cod...

...ot require, no - but it's just intimate enough with my ida rewrite that > I think it makes sense; it makes some use of stuff that should be > internal to the ida code. > > Mostly just sharing the lock though, since I got rid of the ida > interfaces that don't do locking, but percpu ida needs a lock that also > covers what ida needs. > > It also makes use of a ganged allocation interface, but there's no real > reason ida can't expose that, it's just unlikely to be useful to > anything but percpu ida. > > The other reason I think it makes sens...

...ot require, no - but it's just intimate enough with my ida rewrite that > I think it makes sense; it makes some use of stuff that should be > internal to the ida code. > > Mostly just sharing the lock though, since I got rid of the ida > interfaces that don't do locking, but percpu ida needs a lock that also > covers what ida needs. > > It also makes use of a ganged allocation interface, but there's no real > reason ida can't expose that, it's just unlikely to be useful to > anything but percpu ida. > > The other reason I think it makes sens...

...side in the same file? Not require, no - but it's just intimate enough with my ida rewrite that I think it makes sense; it makes some use of stuff that should be internal to the ida code. Mostly just sharing the lock though, since I got rid of the ida interfaces that don't do locking, but percpu ida needs a lock that also covers what ida needs. It also makes use of a ganged allocation interface, but there's no real reason ida can't expose that, it's just unlikely to be useful to anything but percpu ida. The other reason I think it makes sense to live in idr.c is more for user...

...tags to eventually be returned. > > But if a client of this code is using the allocator for something > totally different, there is no guarantee that the act of waiting will > result in any tags being returned. Yeah, and I did wonder a bit whether the waiting mechanism belonged in the percpu ida code; arguably (certainly just looking at this code, not any of the users) if it belongs in this code it should be common to regular ida, not specific to percpu ida. For now I've just decided to punt on changing that for now, since all the percpu ida users I've come across do want the...

...39;s just intimate enough with my ida rewrite that > > I think it makes sense; it makes some use of stuff that should be > > internal to the ida code. > > > > Mostly just sharing the lock though, since I got rid of the ida > > interfaces that don't do locking, but percpu ida needs a lock that also > > covers what ida needs. > > > > It also makes use of a ganged allocation interface, but there's no real > > reason ida can't expose that, it's just unlikely to be useful to > > anything but percpu ida. > > > > The...