On Wed, Oct 10, 2018 at 10:40:12PM -0700, Nicholas A. Bellinger wrote:
> Hey Peter & Co,
>
> On Wed, 2018-10-10 at 10:43 +0200, Peter Zijlstra wrote:
> > On Wed, Oct 10, 2018 at 03:23:10AM +, Nicholas A. Bellinger wrote:
> > > From: Nicholas Bellinger
> > &g
On Wed, Oct 10, 2018 at 03:23:10AM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> With the addition of commit 00d909a107 in v4.19-rc, it incorrectly assumes no
> signals will be pending for task_struct executing the normal session shutdown
> and I/O quiesce code-path.
>
> For
also wait
> for commands that are being aborted")
> Cc: Bart Van Assche
> Cc: Mike Christie
> Cc: Hannes Reinecke
> Cc: Christoph Hellwig
> Cc: Sagi Grimberg
> Cc: Bryant G. Ly
> Cc: Peter Zijlstra (Intel)
> Tested-by: Nicholas Bellinger
> Signed-off-by: Nicholas Bellinger
Acked-by: Peter Zijlstra (Intel)
On Mon, Jan 08, 2018 at 11:43:42AM +, Alan Cox wrote:
> On Mon, 8 Jan 2018 11:08:36 +0100
> Peter Zijlstra wrote:
>
> > On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman
> > > wrote:
&g
On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman
> wrote:
> > In at least one place (mpls) you are patching a fast path. Compile out
> > or don't load mpls by all means. But it is not acceptable to change the
> > fast path without
On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote:
>
> So the overhead looks to be spread out over all sorts, which makes it
> harder to find and fix.
>
> stack unwinding is done lots and is fairly expensive, I've not yet
> checked if crossrelease does too mu
On Wed, Aug 30, 2017 at 03:15:11PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (08/30/17 14:43), Byungchul Park wrote:
> [..]
> > > notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
> > > is irritatingly slow)
> >
> > To Ingo,
> >
> > I cannot decide if we have to roll back C
On Wed, Aug 23, 2017 at 09:03:04AM +0900, Byungchul Park wrote:
> On Tue, Aug 22, 2017 at 09:43:56PM +, Bart Van Assche wrote:
> The report is talking about the following lockup:
>
> A work in a worker A task work on exit to user
> -- --
On Fri, Apr 21, 2017 at 08:03:13AM -0600, Jens Axboe wrote:
> You have it so easy - the code is completely standalone, building a
> small test framework around it and measuring performance in _user space_
> is trivial.
Something like this you mean:
https://lkml.kernel.org/r/20170322165144.dtid
On Mon, Feb 20, 2017 at 07:41:01AM -0800, James Bottomley wrote:
> On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote:
> > On 02/20/2017 04:16 AM, Elena Reshetova wrote:
> > > Now when new refcount_t type and API are finally merged
> > > (see include/linux/refcount.h), the following
> > > patches
On Fri, May 22, 2015 at 05:10:44PM +0200, Tomas Henzl wrote:
> >> I've updated to 6.62 and it appears to be working now; or rather, it has
I've since gotten 6.64 from HP to test; which does not seem public yet.
6.64 actually fixes the issue for me.
> An older issue for mptsas seems to handle a s
On Mon, May 18, 2015 at 06:03:45PM +0200, Peter Zijlstra wrote:
> On Mon, May 18, 2015 at 05:20:34PM +0200, Peter Zijlstra wrote:
> > On Mon, May 18, 2015 at 01:57:39PM +, Oelke, Mark wrote:
> > > The P212/P410/P411 firmware was recently spun to address an issue that
> &g
On Sat, May 17, 2014 at 05:14:13PM -0400, Mikulas Patocka wrote:
> BTW. if we talk about performance - what about replacing:
>
> if (atomic_dec_and_test(&variable)) {
> ... release(object);
> }
>
> with this:
>
> if (atomic_read(&variable) == 1 || atomic_dec_and_t
13 matches
Mail list logo