On Tue, Jan 03, 2017 at 10:29:58PM +1000, Nicholas Piggin wrote:
> > kernel building showed nothing unusual on any machine
> >
> > git checkout in a loop showed;
> > o minor gains with Nick's patch
> > o no impact from Linus's patch
> > o flat performance from PeterZ's
> >
> > git tes
On Tue, 3 Jan 2017 10:24:39 +
Mel Gorman wrote:
> On Thu, Dec 29, 2016 at 03:26:15PM +1000, Nicholas Piggin wrote:
> > > And I fixed that too.
> > >
> > > Of course, I didn't test the changes (apart from building it). But
> > > I've been running the previous version since yesterday, so far n
On Thu, Dec 29, 2016 at 03:26:15PM +1000, Nicholas Piggin wrote:
> > And I fixed that too.
> >
> > Of course, I didn't test the changes (apart from building it). But
> > I've been running the previous version since yesterday, so far no
> > issues.
>
> It looks good to me.
>
FWIW, I blindly queu
On Wed, 28 Dec 2016 20:16:56 -0800
Linus Torvalds wrote:
> On Wed, Dec 28, 2016 at 8:08 PM, Nicholas Piggin wrote:
> >
> > Okay. The name could be a bit better though I think, for readability.
> > Just a BUILD_BUG_ON if it is not constant and correct bit numbers?
>
> I have a slightly edited
On Wed, Dec 28, 2016 at 8:08 PM, Nicholas Piggin wrote:
>
> Okay. The name could be a bit better though I think, for readability.
> Just a BUILD_BUG_ON if it is not constant and correct bit numbers?
I have a slightly edited patch - moved the comments around and added
some new comments (about both
On Wed, 28 Dec 2016 11:17:00 -0800
Linus Torvalds wrote:
> On Tue, Dec 27, 2016 at 7:53 PM, Nicholas Piggin wrote:
> >>
> >> Yeah, that patch is disgusting, and doesn't even help x86.
> >
> > No, although it would help some cases (but granted the bitops tend to
> > be problematic in this regar
On Tue, Dec 27, 2016 at 7:53 PM, Nicholas Piggin wrote:
>>
>> Yeah, that patch is disgusting, and doesn't even help x86.
>
> No, although it would help some cases (but granted the bitops tend to
> be problematic in this regard). To be clear I'm not asking to merge it,
> just wondered your opinion.
On Tue, 27 Dec 2016 10:58:59 -0800
Linus Torvalds wrote:
> On Tue, Dec 27, 2016 at 3:19 AM, Nicholas Piggin wrote:
> >
> > Attached is part of a patch I've been mulling over for a while. I
> > expect you to hate it, and it does not solve this problem for x86,
> > but I like being able to propaga
On Tue, Dec 27, 2016 at 11:40 AM, Linus Torvalds
wrote:
>
> This patch at least might have a chance in hell of working. Let's see..
Ok, with that fixed, things do indeed seem to work.
And things also look fairly good on my "lots of nasty little
shortlived scripts" benchmark ("make -j32 test" for
On Tue, Dec 27, 2016 at 11:24 AM, Linus Torvalds
wrote:
>
> Oops. I should include the actual patch I was talking about too, shouldn't I?
And that patch was completely buggy. The mask for the "and" was computed as
+ : "Ir" (1 << nr) : "memory");
but that clears every bit *except*
On Tue, Dec 27, 2016 at 11:23 AM, Linus Torvalds
wrote:
>
> Of course, none of this is *tested*, but it looks superficially
> correct, and allows other architectures to do the same optimization if
> they want.
Oops. I should include the actual patch I was talking about too, shouldn't I?
On Tue, Dec 27, 2016 at 10:58 AM, Linus Torvalds
wrote:
>
> The other alternative is to keep the lock bit as bit #0, and just make
> the contention bit be the high bit. Then, on x86, you can do
>
> lock andb $0xfe,flags
> js contention
>
> which might be even better. Again, it would be a v
On Tue, Dec 27, 2016 at 3:19 AM, Nicholas Piggin wrote:
>
> Attached is part of a patch I've been mulling over for a while. I
> expect you to hate it, and it does not solve this problem for x86,
> but I like being able to propagate values from atomic ops back
> to the compiler. Of course, volatile
On Mon, 26 Dec 2016 11:07:52 -0800
Linus Torvalds wrote:
> On Sun, Dec 25, 2016 at 5:16 PM, Nicholas Piggin wrote:
> >
> > I did actually play around with that. I could not get my skylake
> > to forward the result from a lock op to a subsequent load (the
> > latency was the same whether you use
On Sun, Dec 25, 2016 at 5:16 PM, Nicholas Piggin wrote:
>
> I did actually play around with that. I could not get my skylake
> to forward the result from a lock op to a subsequent load (the
> latency was the same whether you use lock ; andb or lock ; andl
> (32 cycles for my test loop) whereas wit
On Sun, 25 Dec 2016 13:51:17 -0800
Linus Torvalds wrote:
> On Sat, Dec 24, 2016 at 7:00 PM, Nicholas Piggin wrote:
> > Add a new page flag, PageWaiters, to indicate the page waitqueue has
> > tasks waiting. This can be tested rather than testing waitqueue_active
> > which requires another cachel
On Sat, Dec 24, 2016 at 7:00 PM, Nicholas Piggin wrote:
> Add a new page flag, PageWaiters, to indicate the page waitqueue has
> tasks waiting. This can be tested rather than testing waitqueue_active
> which requires another cacheline load.
Ok, I applied this one too. I think there's room for imp
17 matches
Mail list logo