[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1911120816570.1833@nanos.tec.linutronix.de>
Date: Tue, 12 Nov 2019 08:17:47 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Ingo Molnar <mingo@...nel.org>
cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Linus Torvalds <torvalds@...uxfoundation.org>,
Andy Lutomirski <luto@...nel.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Willy Tarreau <w@....eu>, Juergen Gross <jgross@...e.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [patch V2 11/16] x86/ioperm: Share I/O bitmap if identical
On Tue, 12 Nov 2019, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@...utronix.de> wrote:
> > +void io_bitmap_share(struct task_struct *tsk)
> > + {
> > + /*
> > + * Take a refcount on current's bitmap. It can be used by
> > + * both tasks as long as none of them changes the bitmap.
> > + */
> > + refcount_inc(¤t->thread.io_bitmap->refcnt);
> > + tsk->thread.io_bitmap = current->thread.io_bitmap;
> > + set_tsk_thread_flag(tsk, TIF_IO_BITMAP);
> > +}
>
> Ok, this is really neat. I suspect there might be some pathological cases
> on ancient NUMA systems with a really high NUMA factor and bad caching
> where this new sharing might regress performance, but I doubt this
> matters, as both the hardware and this software functionality is legacy.
Definitely.
> > + /*
> > + * If the bitmap is not shared, then nothing can take a refcount as
> > + * current can obviously not fork at the same time. If it's shared
> > + * duplicate it and drop the refcount on the original one.
> > + */
> > + if (refcount_read(&iobm->refcnt) > 1) {
> > + iobm = kmemdup(iobm, sizeof(*iobm), GFP_KERNEL);
> > + if (!iobm)
> > + return -ENOMEM;
> > + io_bitmap_exit();
> > }
> >
> > + /* Set the tasks io_bitmap pointer (might be the same) */
>
> speling nit:
s/speling/spelling/ :)
> s/tasks
> /task's
Thanks,
tglx
Powered by blists - more mailing lists