On Mon, Jun 29, 2015 at 11:12:20AM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Mon, Jun 29, 2015 at 11:32:19AM +0200, Peter Zijlstra wrote:
> > Agreed, luckily we already have the infrastructure for this, something
> > like so?
> >
> > --- a/include/linux/percpu-defs.h
> > +++ b/include/linux/
Hello, Peter.
On Mon, Jun 29, 2015 at 11:32:19AM +0200, Peter Zijlstra wrote:
> Agreed, luckily we already have the infrastructure for this, something
> like so?
>
> --- a/include/linux/percpu-defs.h
> +++ b/include/linux/percpu-defs.h
> @@ -287,6 +287,16 @@ do {
On Thu, Jun 25, 2015 at 03:17:01PM -0400, Tejun Heo wrote:
> Hmmm... the only worry I have about this is people using it on u64 on
> 32bit machines. CPU local ops can do split updates on lower and upper
> halves and the remotely-read value will be surprising. We have the
> same issues w/ regular
Hello,
On Thu, Jun 25, 2015 at 09:08:00PM +0200, Peter Zijlstra wrote:
> > mm/memcontrol.c:mem_cgroup_read_events
> > mm/memcontrol.c:mem_cgroup_read_stat
>
> Those seem to be hotplug challenged. I'm thinking dropping that
> nocpu_base.count[] crap and just iterating all possible CPUs would've
On Tue, Jun 23, 2015 at 09:28:11AM +0200, Nicholas Mc Guire wrote:
>
> A bit off-topic probably
> but maybe this should not be in kernel/locking/percpu-rwsem.c but in a
> generic percpu location as this construct is present in the core a few times
> atleast in:
> kernel/irq/irqdesc.c:kstat_irqs
A bit off-topic probably
but maybe this should not be in kernel/locking/percpu-rwsem.c but in a
generic percpu location as this construct is present in the core a few times
atleast in:
kernel/irq/irqdesc.c:kstat_irqs
kernel/fork.c:nr_processes
mm/memcontrol.c:mem_cgroup_read_events
mm/memcontr
On 06/22, Peter Zijlstra wrote:
>
> +enum { readers_slow, readers_block };
I still think this enum doesn't make sense, and percpu_rw_semaphore->state
should be a boolean. But this is really minor and subjective.
Reviewed-by: Oleg Nesterov
--
To unsubscribe from this list: send the line "unsubsc
Currently the percpu-rwsem has two issues:
- it switches to (global) atomic ops while a writer is waiting;
which could be quite a while and slows down releasing the readers.
- it employs synchronize_sched_expedited() _twice_ which is evil and
should die -- it shoots IPIs around the machin
8 matches
Mail list logo
