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]

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

On Fri, 2007-07-06 at 16:12 +1000, Nick Piggin wrote:
> Mathieu Desnoyers wrote:

> > migration_disable();
> > local_inc(&__get_cpu_var(&my_local_t_var));
> > migration_enable();
> > 

[...]

> 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.

For this given example, it may be too much fine tuning. But there are
other things (at least in RT) where this would be very helpful. One
thing is that in RT an IRQ thread might service a softirq if that
softirq thread is of the same priority as the IRQ thread. The difference
between an IRQ thread and a softirq thread is that the IRQ thread may
migrate but the softirq thread may not. So to do this performance
enhancement, we need to temporarily pin the IRQ thread to the CPU, which
is expensive (set_cpus_allowed).  This would make it much simpler and
light weight to implement.

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

Agreed, but as the subject says "RFC".  Perhaps we can make it a bit
more complex and put this as one of the most significant bits in the
preempt_count. We would just need to mask off that bit in all the archs
when determining if we should preempt or not.  That's more complex, but
keeps the task struct free from more luggage.

-- Steve

-
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/