On 08/31/2016 06:41 AM, Guenter Roeck wrote:
On 08/31/2016 01:09 AM, Peter Zijlstra wrote:
On Tue, Aug 30, 2016 at 10:21:02PM -0700, Guenter Roeck wrote:
Peter,
The call to rcu_sync_is_idle() causes the following build error when building
x86_64:allmodconfig.
ERROR: "rcu_sync_lockdep_assert"
On 08/31/2016 01:09 AM, Peter Zijlstra wrote:
On Tue, Aug 30, 2016 at 10:21:02PM -0700, Guenter Roeck wrote:
Peter,
The call to rcu_sync_is_idle() causes the following build error when building
x86_64:allmodconfig.
ERROR: "rcu_sync_lockdep_assert" [kernel/locking/locktorture.ko] undefined!
ERR
On Tue, Aug 30, 2016 at 10:21:02PM -0700, Guenter Roeck wrote:
> Peter,
>
> The call to rcu_sync_is_idle() causes the following build error when building
> x86_64:allmodconfig.
>
> ERROR: "rcu_sync_lockdep_assert" [kernel/locking/locktorture.ko] undefined!
> ERROR: "rcu_sync_lockdep_assert" [fs/e
Peter,
On Tue, Aug 09, 2016 at 11:51:12AM +0200, Peter Zijlstra wrote:
> Currently the percpu-rwsem switches to (global) atomic ops while a
> writer is waiting; which could be quite a while and slows down
> releasing the readers.
>
> This patch cures this problem by ordering the reader-state vs
>
On 8/26/2016 9:47 AM, Dmitry Shmidt wrote:
On Fri, Aug 26, 2016 at 5:51 AM, Tejun Heo wrote:
Hello, John.
On Thu, Aug 25, 2016 at 07:14:07PM -0700, John Stultz wrote:
Hey! Good news. This patch along with Peter's locking changes pushes
the latencies down to an apparently acceptable level!
On Fri, Aug 26, 2016 at 5:51 AM, Tejun Heo wrote:
> Hello, John.
>
> On Thu, Aug 25, 2016 at 07:14:07PM -0700, John Stultz wrote:
>> Hey! Good news. This patch along with Peter's locking changes pushes
>> the latencies down to an apparently acceptable level!
>
> Ah, that's good to hear. Please fe
Hello, John.
On Thu, Aug 25, 2016 at 07:14:07PM -0700, John Stultz wrote:
> Hey! Good news. This patch along with Peter's locking changes pushes
> the latencies down to an apparently acceptable level!
Ah, that's good to hear. Please feel free to ping me if you guys
wanna talk about cgroup usage
On Wed, Aug 24, 2016 at 2:30 PM, Tejun Heo wrote:
> Hello, John.
>
> On Wed, Aug 24, 2016 at 02:16:52PM -0700, John Stultz wrote:
>> Hey Peter, Tejun, Oleg,
>> So while you're tweaks for the percpu-rwsem have greatly helped the
>> regression folks were seeing (many thanks, by the way), as noted
On Wed, Aug 24, 2016 at 2:30 PM, Tejun Heo wrote:
> On Wed, Aug 24, 2016 at 02:16:52PM -0700, John Stultz wrote:
>>
>> So I was wondering if patches to go back to the per signal_struct
>> locking would still be considered? Or is the global lock approach the
>> only way forward?
>
> We can't simply
Hello, John.
On Wed, Aug 24, 2016 at 02:16:52PM -0700, John Stultz wrote:
> Hey Peter, Tejun, Oleg,
> So while you're tweaks for the percpu-rwsem have greatly helped the
> regression folks were seeing (many thanks, by the way), as noted
> above, the performance regression with the global lock co
On Fri, Aug 12, 2016 at 6:44 PM, Om Dhyade wrote:
> Update from my tests:
> Use-case: Android application launches.
>
> I tested the patches on android N build, i see max latency ~7ms.
> In my tests, the wait is due to: copy_process(fork.c) blocks all threads in
> __cgroup_procs_write including th
Thank you Dimtry for sharing the patches.
Update from my tests:
Use-case: Android application launches.
I tested the patches on android N build, i see max latency ~7ms.
In my tests, the wait is due to: copy_process(fork.c) blocks all threads
in __cgroup_procs_write including threads which are n
On Tue, Aug 09, 2016 at 04:47:38PM -0700, John Stultz wrote:
> On Tue, Aug 9, 2016 at 2:51 AM, Peter Zijlstra wrote:
> >
> > Currently the percpu-rwsem switches to (global) atomic ops while a
> > writer is waiting; which could be quite a while and slows down
> > releasing the readers.
> >
> > This
On 08/10, Peter Zijlstra wrote:
>
> On Tue, Aug 09, 2016 at 04:47:38PM -0700, John Stultz wrote:
> > On Tue, Aug 9, 2016 at 2:51 AM, Peter Zijlstra wrote:
> > >
> > > Currently the percpu-rwsem switches to (global) atomic ops while a
> > > writer is waiting; which could be quite a while and slows
On Tue, Aug 9, 2016 at 2:51 AM, Peter Zijlstra wrote:
>
> Currently the percpu-rwsem switches to (global) atomic ops while a
> writer is waiting; which could be quite a while and slows down
> releasing the readers.
>
> This patch cures this problem by ordering the reader-state vs
> reader-count (s
Currently the percpu-rwsem switches to (global) atomic ops while a
writer is waiting; which could be quite a while and slows down
releasing the readers.
This patch cures this problem by ordering the reader-state vs
reader-count (see the comments in __percpu_down_read() and
percpu_down_write()). T
16 matches
Mail list logo
