[lkml]   [2001]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Feedback on preemptible kernel patch
On Fri, 2001-09-14 at 03:30, george anzinger wrote:
> Right, the same problem as using floating point in the kernel (mmx uses
> the FP regs and they are not saved).

Right, and I suspect we will find more problems of this type as we go
on. In fact, the more general case "things that are SMP-safe but not
preempt safe" will be issues, too. The highmem bug was one of these -
code that was SMP-safe but did not have lock points because it was
per-CPU code. Preemption ruins all that.

> The question is: Just how long do these routines take? If it is very long
> it may be best to just say no. One way would be to always pretend that
> the"in_interrupt" flag is set. I think possibly some routines are
> short and the switch off/ switch on pair is right, but for the long ones,
> well the preemption patch is supposed to make the kernel more preemptable,
> not less. Any one have execution times for these functions?

Well, its the routines in arch/i386/lib/mmx.c -- and just the ones that
call kernel_begin/end_fpu. My patch pushes a ctx_sw_off/on pair into
those functions. Anyhow, if you look, they aren't too long.

However, I agree that we may be destroying our purpose here. A user of
the patch actually put together a patch that will disable the CONFIG to
use the fast MMX memcpy stuff if preemption was enabled. He benchmarked
against the two and I can send you those results when I sort through

Robert M. Love
rml at
rml at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.068 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site