4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Trofimovich
commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
Fix page fault handling code to fixup r16-r18 registers.
Before the patch code had off-by-two registers bug.
This
Hum, weird. I have hard time understanding how that change could be causing
fs corruption on Aplha but OTOH it is not completely unthinkable. With this
commit we may migrate some block device pages we were not able to migrate
previously and that could be causing some unexpected issue. I'll look
On Sun 17-02-19 00:29:40, Meelis Roos wrote:
> > > The result of the bisection is
> > > [88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls
> > > for blkdev pages
> > >
> > > Is that result relevant for the problem or should I continue bisecting
> > > between 4.20.0 and
The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for
blkdev pages
Is that result relevant for the problem or should I continue bisecting between
4.20.0 and the so far first bad commit?
Can you try reverting the commit and see if it
On Fri, Feb 15, 2019 at 06:59:48PM +0200, Meelis Roos wrote:
> The result of the bisection is
> [88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for
> blkdev pages
>
> Is that result relevant for the problem or should I continue bisecting
> between 4.20.0 and the so far
On 02/15/2019 01:40 PM, Will Deacon wrote:
> On Thu, Feb 14, 2019 at 11:37:15AM +0100, Peter Zijlstra wrote:
>> On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
>>> v4:
>>> - Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
>>>
>>> v3:
>>> - Optimize __down_read_trylock()
On Thu, Feb 14, 2019 at 11:37:15AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
> > v4:
> > - Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
> >
> > v3:
> > - Optimize __down_read_trylock() for the uncontended case as suggested
> >
On Thu, Feb 14, 2019 at 10:09:44AM -0800, Linus Torvalds wrote:
> On Thu, Feb 14, 2019 at 9:51 AM Linus Torvalds
> wrote:
> >
> > The arm64 numbers scaled horribly even before, and that's because
> > there is too much ping-pong, and it's probably because there is no
> > "stickiness" to the
I have noticed ext4 filesystem corruption on two of my test alphas with
4.20.0-09062-gd8372ba8ce28.
Retried it, still happens with 5.0.0-rc5-00358-gdf3865f8f568 - rsync of emerge
--sync just fail with nothing in dmesg.
Finished second round of bisecting, first round did not get me far
On 02/14/2019 05:37 AM, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
>> v4:
>> - Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
>>
>> v3:
>> - Optimize __down_read_trylock() for the uncontended case as suggested
>>by Linus.
>>
>> v2:
>>
On 02/14/2019 01:02 PM, Will Deacon wrote:
> On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
>> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
>>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>>> it generate slightly better code.
>>>
>>>
On Thu, Feb 14, 2019 at 9:51 AM Linus Torvalds
wrote:
>
> The arm64 numbers scaled horribly even before, and that's because
> there is too much ping-pong, and it's probably because there is no
> "stickiness" to the cacheline to the core, and thus adding the extra
> loop can make the ping-pong
On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
> > Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> > it generate slightly better code.
> >
> > Before this patch, down_read_trylock:
> >
> >
On Thu, Feb 14, 2019 at 6:53 AM Waiman Long wrote:
>
> The ARM64 result is what I would have expected given that the change was
> to optimize for the uncontended case. The x86-64 result is kind of an
> anomaly to me, but I haven't bothered to dig into that.
I would say that the ARM result is
On 02/14/2019 08:23 AM, Davidlohr Bueso wrote:
> On Fri, 08 Feb 2019, Waiman Long wrote:
>> I am planning to run more performance test and post the data sometimes
>> next week. Davidlohr is also going to run some of his rwsem performance
>> test on this patchset.
>
> So I ran this series on a
On 02/14/2019 05:33 AM, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>> it generate slightly better code.
>>
>> Before this patch, down_read_trylock:
>>
>>0x <+0>:
On Fri, 08 Feb 2019, Waiman Long wrote:
I am planning to run more performance test and post the data sometimes
next week. Davidlohr is also going to run some of his rwsem performance
test on this patchset.
So I ran this series on a 40-core IB 2 socket with various worklods in
mmtests. Below
On Thu, Feb 14, 2019 at 11:54:47AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 13, 2019 at 11:01 PM Waiman Long wrote:
> > Currently, we have two different implementation of rwsem:
> > 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
> > 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
>
On Wed, Feb 13, 2019 at 11:01 PM Waiman Long wrote:
> Currently, we have two different implementation of rwsem:
> 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
> 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
>
> As we are going to use a single generic implementation for rwsem-xadd.c
>
On Wed, Feb 13, 2019 at 05:00:14PM -0500, Waiman Long wrote:
> v4:
> - Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
>
> v3:
> - Optimize __down_read_trylock() for the uncontended case as suggested
>by Linus.
>
> v2:
> - Add patch 2 to optimize __down_read_trylock() as
On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> it generate slightly better code.
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
Modify __down_read_trylock() to optimize for an unlocked rwsem and make
it generate slightly better code.
Before this patch, down_read_trylock:
0x <+0>: callq 0x5
0x0005 <+5>: jmp0x18
0x0007 <+7>: lea0x1(%rdx),%rcx
Currently, we have two different implementation of rwsem:
1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c)
2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)
As we are going to use a single generic implementation for rwsem-xadd.c
and no architecture-specific code will be needed, there is no
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code as long as the
atomic functions are properly implemented. So we can remove those arch
specific rwsem.h
v4:
- Remove rwsem-spinlock.c and make all archs use rwsem-xadd.c.
v3:
- Optimize __down_read_trylock() for the uncontended case as suggested
by Linus.
v2:
- Add patch 2 to optimize __down_read_trylock() as suggested by PeterZ.
- Update performance test data in patch 1.
The goal of this
Modify __down_read_trylock() to optimize for an unlocked rwsem and make
it generate slightly better code.
Before this patch, down_read_trylock:
0x <+0>: callq 0x5
0x0005 <+5>: jmp0x18
0x0007 <+7>: lea0x1(%rdx),%rcx
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code as long as the
atomic functions are properly implemented. So we can remove those arch
specific rwsem.h
v3:
- Optimize __down_read_trylock() for the uncontended case as suggested
by Linus.
v2:
- Add patch 2 to optimize __down_read_trylock() as suggested by PeterZ.
- Update performance test data in patch 1.
This is part 0 of my rwsem patchset. It just removes the architecture
specific files
On 02/13/2019 02:45 AM, Ingo Molnar wrote:
> * Waiman Long wrote:
>
>> I looked at the assembly code in arch/x86/include/asm/rwsem.h. For both
>> trylocks (read & write), the count is read first before attempting to
>> lock it. We did the same for all trylock functions in other locks.
>>
* Waiman Long wrote:
> I looked at the assembly code in arch/x86/include/asm/rwsem.h. For both
> trylocks (read & write), the count is read first before attempting to
> lock it. We did the same for all trylock functions in other locks.
> Depending on how the trylock is used and how contended
On 02/12/2019 02:58 PM, Linus Torvalds wrote:
> On Mon, Feb 11, 2019 at 11:31 AM Waiman Long wrote:
>> Modify __down_read_trylock() to make it generate slightly better code
>> (smaller and maybe a tiny bit faster).
> This looks good, but I would ask you to try one slightly different approach.
>
>
On Mon, Feb 11, 2019 at 11:31 AM Waiman Long wrote:
>
> Modify __down_read_trylock() to make it generate slightly better code
> (smaller and maybe a tiny bit faster).
This looks good, but I would ask you to try one slightly different approach.
Instead of this:
>long tmp =
On Sun, Feb 10, 2019 at 7:21 PM Deepa Dinamani wrote:
>
> On Feb 10, 2019, at 7:43 AM, Ran Rozenstein wrote:
>
> >> Subject: [PATCH net-next v5 09/12] socket: Add SO_TIMESTAMPING_NEW
> >>
> >> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
> >> This is the y2038 safe versions of
On 02/12/2019 01:36 PM, Waiman Long wrote:
> On 02/12/2019 08:25 AM, Peter Zijlstra wrote:
>> On Tue, Feb 12, 2019 at 02:24:04PM +0100, Peter Zijlstra wrote:
>>> On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
Modify __down_read_trylock() to make it generate slightly better code
On Mon, Feb 11, 2019 at 02:31:26PM -0500, Waiman Long wrote:
> Modify __down_read_trylock() to make it generate slightly better code
> (smaller and maybe a tiny bit faster).
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>:
v2:
- Add patch 2 to optimize __down_read_trylock() as suggested by PeterZ.
- Update performance test data in patch 1.
This is part 0 of my rwsem patchset. It just removes the architecture
specific files to make it easer to add enhancements in the upcoming
rwsem patches.
Since the two ll/sc
Modify __down_read_trylock() to make it generate slightly better code
(smaller and maybe a tiny bit faster).
Before this patch, down_read_trylock:
0x <+0>: callq 0x5
0x0005 <+5>: jmp0x18
0x0007 <+7>: lea0x1(%rdx),%rcx
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code as long as the
atomic functions are properly implemented. So we can remove those arch
specific rwsem.h
The pull request you sent on Sun, 10 Feb 2019 20:46:15 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/244cce14c17705e6376cd12c20c27f8712793acc
Thank you!
--
Deet-doot-dot, I am a
On Mon, Feb 11, 2019 at 11:35:24AM -0500, Waiman Long wrote:
> On 02/11/2019 06:58 AM, Peter Zijlstra wrote:
> > Which is clearly worse. Now we can write that as:
> >
> > int __down_read_trylock2(unsigned long *l)
> > {
> > long tmp = READ_ONCE(*l);
> >
> > while (tmp >= 0) {
> >
On 02/11/2019 06:58 AM, Peter Zijlstra wrote:
> Which is clearly worse. Now we can write that as:
>
> int __down_read_trylock2(unsigned long *l)
> {
> long tmp = READ_ONCE(*l);
>
> while (tmp >= 0) {
> if (try_cmpxchg(l, , tmp + 1))
>
On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> +static inline int __down_read_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + while ((tmp = atomic_long_read(>count)) >= 0) {
> + if (tmp == atomic_long_cmpxchg_acquire(>count, tmp,
> +
On Mon, Feb 11, 2019 at 10:40:44AM +0100, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> > On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > > +{
> > > + long tmp;
> > >
* Will Deacon wrote:
> On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
> >
> > * Ingo Molnar wrote:
> >
> > > Sounds good to me - I've merged this patch, will push it out after
> > > testing.
> >
> > Based on Peter's feedback I'm delaying this - performance testing on at
> >
On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > Sounds good to me - I've merged this patch, will push it out after
> > testing.
>
> Based on Peter's feedback I'm delaying this - performance testing on at
> least one key ll/sc arch would be nice
* Ingo Molnar wrote:
> Sounds good to me - I've merged this patch, will push it out after
> testing.
Based on Peter's feedback I'm delaying this - performance testing on at
least one key ll/sc arch would be nice indeed.
Thanks,
Ingo
On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > +{
> > + long tmp;
> > +
> > + while ((tmp = atomic_long_read(>count)) >= 0) {
> > +
On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
> index bad2bca..067e265 100644
> --- a/kernel/locking/rwsem.h
> +++ b/kernel/locking/rwsem.h
> @@ -32,6 +32,26 @@
> # define DEBUG_RWSEMS_WARN_ON(c)
> #endif
>
> +/*
> +
* Waiman Long wrote:
> On 02/07/2019 02:51 PM, Davidlohr Bueso wrote:
> > On Thu, 07 Feb 2019, Waiman Long wrote:
> >> 30 files changed, 1197 insertions(+), 1594 deletions(-)
> >
> > Performance numbers on numerous workloads, pretty please.
> >
> > I'll go and throw this at my mmap_sem
* Waiman Long wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> >
Hi Linus,
Please pull a few changes for alpha, including a build fix, a fix for the Eiger
platform, and a fix for a tricky bug uncovered by the strace test suite that
has existed since at least 1997 (v2.1.32)!
Thanks,
Matt
The following changes since commit
On Feb 10, 2019, at 7:43 AM, Ran Rozenstein wrote:
>> Subject: [PATCH net-next v5 09/12] socket: Add SO_TIMESTAMPING_NEW
>>
>> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
>> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD for all
>> architectures.
>>
>> Signed-off-by:
On 02/10/2019 09:00 PM, Waiman Long wrote:
> As the generic rwsem-xadd code is using the appropriate acquire and
> release versions of the atomic operations, the arch specific rwsem.h
> files will not be that much faster than the generic code as long as the
> atomic functions are properly
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code as long as the
atomic functions are properly implemented. So we can remove those arch
specific rwsem.h
Deepa Dinamani writes:
>> You touched powerpc in the previous patch but not this one.
>>
>> That's because we use the asm-generic version I assume.
>
> That is correct.
>
>> Would be good to mention in the change log though to avoid any confusion.
>
> I'm not sure how to do that now. It looks
02.01.19 17:52 I wrote:
I have noticed ext4 filesystem corruption on two of my test alphas with
4.20.0-09062-gd8372ba8ce28.
Retried it, still happens with 5.0.0-rc5-00358-gdf3865f8f568 - rsync of emerge
--sync just fail with nothing in dmesg.
On AlphaServer DS10:
[10749.664418] EXT4-fs
> Subject: [PATCH net-next v5 09/12] socket: Add SO_TIMESTAMPING_NEW
>
> Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
> This is the y2038 safe versions of the SO_TIMESTAMPING_OLD for all
> architectures.
>
> Signed-off-by: Deepa Dinamani
> Acked-by: Willem de Bruijn
Hi,
I
> You touched powerpc in the previous patch but not this one.
>
> That's because we use the asm-generic version I assume.
That is correct.
> Would be good to mention in the change log though to avoid any confusion.
I'm not sure how to do that now. It looks like the series has already
been
On Fri, Feb 8, 2019 at 12:31 PM Waiman Long wrote:
>
> > (b) what's the new fastpath case
>
> The only change in the fastpath is the use of cmpxchg for writer lock.
.. since a big deal here was about using the generic atomic accessor
functions, I really was looking forward to seeing the
On 02/08/2019 02:50 PM, Linus Torvalds wrote:
> On Thu, Feb 7, 2019 at 11:08 AM Waiman Long wrote:
>> This patchset revamps the current rwsem-xadd implementation to make
>> it saner and easier to work with. This patchset removes all the
>> architecture specific assembly code and uses generic C
On Thu, Feb 7, 2019 at 11:08 AM Waiman Long wrote:
>
> This patchset revamps the current rwsem-xadd implementation to make
> it saner and easier to work with. This patchset removes all the
> architecture specific assembly code and uses generic C code for all
> architectures. This eases
On 02/07/2019 03:54 PM, Waiman Long wrote:
> On 02/07/2019 03:08 PM, Peter Zijlstra wrote:
>> On Thu, Feb 07, 2019 at 02:07:19PM -0500, Waiman Long wrote:
>>> On 32-bit architectures, there aren't enough bits to hold both.
>>> 64-bit architectures, however, can have enough bits to do that. For
>>>
Now that we have 3 mmap flags shared by all architectures,
let's move them into the common header.
This will help discourage future architectures from duplicating code.
Signed-off-by: Michael S. Tsirkin
---
arch/alpha/include/uapi/asm/mman.h | 4 +---
arch/mips/include/uapi/asm/mman.h
Now that we have 3 mmap flags shared by all architectures,
let's move them into the common header.
This will help discourage future architectures from duplicating code.
Signed-off-by: Michael S. Tsirkin
---
arch/alpha/include/uapi/asm/mman.h | 4 +---
arch/mips/include/uapi/asm/mman.h
On 02/07/2019 03:08 PM, Peter Zijlstra wrote:
> On Thu, Feb 07, 2019 at 02:07:19PM -0500, Waiman Long wrote:
>> On 32-bit architectures, there aren't enough bits to hold both.
>> 64-bit architectures, however, can have enough bits to do that. For
>> x86-64, the physical address can use up to 52
On Thu, Feb 07, 2019 at 02:07:19PM -0500, Waiman Long wrote:
> On 32-bit architectures, there aren't enough bits to hold both.
> 64-bit architectures, however, can have enough bits to do that. For
> x86-64, the physical address can use up to 52 bits. That is 4PB of
> memory. That leaves 12 bits
On 02/07/2019 02:51 PM, Davidlohr Bueso wrote:
> On Thu, 07 Feb 2019, Waiman Long wrote:
>> 30 files changed, 1197 insertions(+), 1594 deletions(-)
>
> Performance numbers on numerous workloads, pretty please.
>
> I'll go and throw this at my mmap_sem intensive workloads
> I've collected.
>
>
On Thu, 07 Feb 2019, Waiman Long wrote:
30 files changed, 1197 insertions(+), 1594 deletions(-)
Performance numbers on numerous workloads, pretty please.
I'll go and throw this at my mmap_sem intensive workloads
I've collected.
Thanks,
Davidlohr
On Thu, Feb 07, 2019 at 08:36:56PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 07, 2019 at 02:07:08PM -0500, Waiman Long wrote:
>
> > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > +{
> > + long tmp;
> > +
> > + while ((tmp = atomic_long_read(>count)) >= 0) {
> > +
On Thu, Feb 07, 2019 at 02:07:19PM -0500, Waiman Long wrote:
> On 32-bit architectures, there aren't enough bits to hold both.
> 64-bit architectures, however, can have enough bits to do that. For
> x86-64, the physical address can use up to 52 bits. That is 4PB of
> memory. That leaves 12 bits
On 02/07/2019 02:36 PM, Peter Zijlstra wrote:
> On Thu, Feb 07, 2019 at 02:07:08PM -0500, Waiman Long wrote:
>
>> +static inline int __down_read_trylock(struct rw_semaphore *sem)
>> +{
>> +long tmp;
>> +
>> +while ((tmp = atomic_long_read(>count)) >= 0) {
>> +if (tmp ==
On Thu, Feb 07, 2019 at 02:07:08PM -0500, Waiman Long wrote:
> +static inline int __down_read_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + while ((tmp = atomic_long_read(>count)) >= 0) {
> + if (tmp == atomic_long_cmpxchg_acquire(>count, tmp,
> +
The percpu event counts used by qspinlock code can be useful for
other locking code as well. So a new set of lockevent_* counting APIs
is introduced with the lock event names extracted out into the new
lock_events_list.h header file for easier addition in the future.
The existing qstat_inc()
This patch enables readers to optimistically spin on a
rwsem when it is owned by a writer instead of going to sleep
directly. The rwsem_can_spin_on_owner() function is extracted
out of rwsem_optimistic_spin() and is called directly by
__rwsem_down_read_failed_common() and
Add lock event counting calls so that we can track the number of lock
events happening in the rwsem code.
With CONFIG_LOCK_EVENT_COUNTS on and booting a 1-socket 22-core
44-thread x86-64 system, the non-zero rwsem counts after system bootup
were as follows:
rwsem_opt_fail=113
When rwsem_down_read_failed*() return, the read lock is acquired
indirectly by others. So debug checks are added in __down_read() and
__down_read_killable() to make sure the rwsem is really reader-owned.
The other debug check calls in kernel/locking/rwsem.c except the
one in up_read_non_owner()
The QUEUED_LOCK_STAT option to report queued spinlocks event counts
was previously allowed only on x86 architecture. To make the locking
event counting code more useful, it is now renamed to a more generic
LOCK_EVENT_COUNTS config option. This new option will be available to
all the architectures
Currently, the DEBUG_RWSEMS_WARN_ON() macro just dumps a stack trace
when the rwsem isn't in the right state. It does not show the actual
states of the rwsem. This may not be that helpful in the debugging
process.
Enhance the DEBUG_RWSEMS_WARN_ON() macro to also show the current
content of the
The rwsem_down_read_failed*() functions were relocted from above the
optimistic spinning section to below that section. This enables the
reader functions to use optimisitic spinning in future patches. There
is no code change.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c | 172
The current way of using various reader, writer and waiting biases
in the rwsem code are confusing and hard to understand. I have to
reread the rwsem count guide in the rwsem-xadd.c file from time to
time to remind myself how this whole thing works. It also makes the
rwsem code harder to be
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can help performance by avoiding
spinning on the
As the generic rwsem-xadd code is using the appropriate acquire and
release versions of the atomic operations, the arch specific rwsem.h
files will not be that much faster than the generic code. So we can
remove those arch specific rwsem.h and stop building asm/rwsem.h to
reduce maintenance
An RT task can do optimistic spinning only if the lock holder is
actually running. If the state of the lock holder isn't known, there
is a possibility that high priority of the RT task may block forward
progress of the lock holder if they happen to reside on the same CPU.
This will lead to
On 64-bit architectures, each rwsem writer will have its unique lock
word for acquiring the lock. Right now, the writer code recomputes the
lock word every time it tries to acquire the lock. This is a waste of
time. The lock word is now cached and reused when it is needed.
On 32-bit
With separate count and owner, there are timing windows where the two
values are inconsistent. That can cause problem when trying to figure
out the exact state of the rwsem. For instance, a RT task will stop
optimistic spinning if the lock is acquired by a writer but the owner
field isn't set yet.
After merging the owner value directly into the count field, it was
found that the number of failed optimistic spinning operations increased
significantly during the boot up process.
The cause of this increased failures was tracked down to the condition
that a lock holder might have just released
The setting of owner field is specific to rwsem-xadd code, it is not needed
for rwsem-spinlock. This patch moves all the owner setting code closer
to the rwsem-xadd fast paths directly within rwsem.h file.
For __down_read() and __down_read_killable(), it is assumed that
rwsem will be marked as
We don't need to expose rwsem internal functions which are not supposed
to be called directly from other kernel code.
Signed-off-by: Waiman Long
---
include/linux/rwsem.h | 7 ---
kernel/locking/rwsem-xadd.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git
The content of kernel/locking/rwsem.h is now specific to rwsem-xadd only.
Rename it to rwsem-xadd.h to indicate that it is specific to rwsem-xadd
and include it only when CONFIG_RWSEM_XCHGADD_ALGORITHM is set.
Signed-off-by: Waiman Long
---
kernel/locking/percpu-rwsem.c | 4 +-
This patchset revamps the current rwsem-xadd implementation to make
it saner and easier to work with. This patchset removes all the
architecture specific assembly code and uses generic C code for all
architectures. This eases maintenance and enables us to enhance the
code more easily.
This
On Wed, Feb 6, 2019 at 12:04 AM Meelis Roos wrote:
>
> I share my experience of fresh install of and embedded SBC Alpha
> (Eiger with EV6 500 MHz).
>
> Only an ancient Debian installer worked for me. The reason appeared to
> be broken IRQ numbers for Eiger.
>
> So I used 2 disks. I first
On Thu, 7 Feb 2019, Maciej W. Rozycki wrote:
> Well, at this point I think it makes sense to just resend the patch. In
> case that helps I may offer you my Reviewed-by tag as the change looks
> obviously correct to me; `eiger_mv.nr_irqs' is 128 and we need to match it
> here.
FWIW, it's
On Wed, 6 Feb 2019, Meelis Roos wrote:
> Then I debugged the new kernel and fixed the IRQ problem. Now I had a
> recent kernel. I sent the patch https://lkml.org/lkml/2018/10/12/379 to
> linux-alpha but it seems to have been ignored - PING!
You may have previously been covered by
Deepa Dinamani writes:
> SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> as the time format. struct timeval is not y2038 safe.
> The subsequent patches in the series add support for new socket
> timeout options with _NEW suffix that will use y2038 safe
> data structures. Although
Deepa Dinamani writes:
> Add new socket timeout options that are y2038 safe.
>
> Signed-off-by: Deepa Dinamani
> Acked-by: Willem de Bruijn
> Cc: ccaul...@redhat.com
> Cc: da...@davemloft.net
> Cc: del...@gmx.de
> Cc: pau...@samba.org
> Cc: r...@linux-mips.org
> Cc: r...@twiddle.net
> Cc:
I share my experience of fresh install of and embedded SBC Alpha
(Eiger with EV6 500 MHz).
Only an ancient Debian installer worked for me. The reason appeared to
be broken IRQ numbers for Eiger.
So I used 2 disks. I first installed the ancient Debian on disk 1.
That worked.
Next, I used that
3.16.63-rc1 review patch. If anyone has any objections, please let me know.
--
From: "H. Peter Anvin (Intel)"
commit d0ffb805b729322626639336986bc83fc2e60871 upstream.
Alpha has had c_ispeed and c_ospeed, but still set speeds in c_cflags
using arbitrary flags. Because BOTHER
On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote:
> Mike Rapoport writes:
>
> > Currently, memblock has several internal functions with overlapping
> > functionality. They all call memblock_find_in_range_node() to find free
> > memory and then reserve the allocated range and mark
801 - 900 of 2609 matches
Mail list logo
