linux-kernel - Re: [RFC] Thread Migration Preemption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Jul 2007 10:34:09 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] Thread Migration Preemption

* Nick Piggin (nickpiggin@...oo.com.au) wrote:
> Mathieu Desnoyers wrote:
> >Thread Migration Preemption
> >
> >This patch adds the ability to protect critical sections from migration to
> >another CPU without disabling preemption.
> >
> >This will be useful to minimize the amount of preemption disabling for the 
> >-rt
> >patch. It will help leveraging improvements brought by the local_t types in
> >asm/local.h (see Documentation/local_ops.txt). Note that the updates done 
> >to
> >variables protected by migration_disable must be either atomic or 
> >protected from
> >concurrent updates done by other threads.
> >
> >Typical use:
> >
> >migration_disable();
> >local_inc(&__get_cpu_var(&my_local_t_var));
> >migration_enable();
> >
> >Which will increment the variable atomically wrt the local CPU.
> >
> >Comments (such as how to integrate this in the already almost full
> >preempt_count) are welcome.
> 
> This seems like way too much stuff to add just for this type of thing. Why
> not just disable and reenable preempt? Surely local_inc is not going to take
> so long that disabling preemption matters.
> 

Disabling preemption seems to cause some discomfort in the RT community.
Steven already noticed that they could leverage migration disabling to
enhance the way they deal with softirqs. Basically, anything that must
be tied to a CPU for a short time, can deal with concurrency from other
threads running on the same CPU, but where we do not want to add to the
scheduler latency would be a good prospect for the migration_disable().

> The task struct is not something we should just be carefree putting crap
> into because it is seemingly free :(
> 

I agree. I added it knowing that we could either pack this in the
preempt_count (using masks, if there is still room, which does not seem
to be the case) or, if not, people who could make extensive use of this
could justify adding this field to the thread_info struct. I am barely
sending the idea out there so it can be helpful for the RT team.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/