On Sun, Nov 9, 2014 at 3:51 AM, Paul E. McKenney
wrote:
> On Sun, Nov 09, 2014 at 03:24:34AM +0400, Alexander Monakov wrote:
>> On Sun, Nov 9, 2014 at 1:13 AM, Paul E. McKenney
>> wrote:
>> >
>> > Did anyone try replacing the synchronize_rcu() with
>> > synchronize_rcu_expedited()? That should p
On Sun, Nov 09, 2014 at 03:24:34AM +0400, Alexander Monakov wrote:
> On Sun, Nov 9, 2014 at 1:13 AM, Paul E. McKenney
> wrote:
> >
> > Did anyone try replacing the synchronize_rcu() with
> > synchronize_rcu_expedited()? That should provide substantial speedups
> > over synchronize_rcu().
>
> I'v
On Sun, Nov 9, 2014 at 1:13 AM, Paul E. McKenney
wrote:
>
> Did anyone try replacing the synchronize_rcu() with
> synchronize_rcu_expedited()? That should provide substantial speedups
> over synchronize_rcu().
I've just briefly tested it on my laptop, and it also helps to avoid the issue.
Alexa
On Sat, Nov 08, 2014 at 12:47:17PM +0400, Konstantin Khlebnikov wrote:
> ACPI maintains cache of ioremap regions to speed up operations and
> access to them from irq context where ioremap() calls aren't allowed.
> This code abuses synchronize_rcu() on unmap path for synchronization
> with fast-path
ACPI maintains cache of ioremap regions to speed up operations and
access to them from irq context where ioremap() calls aren't allowed.
This code abuses synchronize_rcu() on unmap path for synchronization
with fast-path in acpi_os_read/write_memory which uses this cache.
Since v3.10 CPUs are allo
5 matches
Mail list logo