[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzKuiLS0CvTTqo5=8eyoksC1==30+XMiXZhQqzXr9JM3A@mail.gmail.com>
Date: Tue, 27 Dec 2016 11:23:19 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Bob Peterson <rpeterso@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Steven Whitehouse <swhiteho@...hat.com>,
Andrew Lutomirski <luto@...nel.org>,
Andreas Gruenbacher <agruenba@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
linux-mm <linux-mm@...ck.org>,
Mel Gorman <mgorman@...hsingularity.net>
Subject: Re: [PATCH 2/2] mm: add PageWaiters indicating tasks are waiting for
a page bit
On Tue, Dec 27, 2016 at 10:58 AM, Linus Torvalds
<torvalds@...ux-foundation.org> 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 very special
> operation just for unlock. Something like
>
> bit_clear_and_branch_if_negative_byte(mem, label);
>
> and again, it would be trivial to do on most architectures.
>
> Let me try to write a patch or two for testing.
Ok, that was easy.
Of course, none of this is *tested*, but it looks superficially
correct, and allows other architectures to do the same optimization if
they want.
On x86, the unlock_page() code now generates
lock; andb $1,(%rdi) #, MEM[(volatile long int *)_7]
js .L114 #,
popq %rbp #
ret
for the actual unlock itself.
Now to actually compile the whole thing and see if it boots..
Linus
Powered by blists - more mailing lists