On Wed, 27 Dec 2000, Andrew Morton wrote:
>
> - Introduces a kernel-wide macro `SMP_KERNEL'. This is designed to
> be used as a `compiled ifdef' in place of `#ifdef CONFIG_SMP'. There
> are a few examples in __wake_up_common().
Please don't do this, it screws up the config option autodetection in
"make checkconfig", and also while gcc is reasonably good at deleting dead
code, gcc has absolutely no clue at all about deleting dead variables, and
will leave the stack slots around giving bigger stack usage and worse
cache behaviour.
(The gcc stack slot problem is a generic gcc problem - your approach just
tends to make it worse).
If you want to do this locally somewhere, that's ok, but keep it local.
> - SLEEP_ON_VAR, SLEEP_ON_HEAD and SLEEP_ON_TAIL have been changed. I
> see no valid reason why these functions were, effectively, doing
> this:
>
> spin_lock_irqsave(lock, flags);
> spin_unlock(lock);
> schedule();
> spin_lock(lock);
> spin_unlock_irqrestore(lock, flags);
>
> What's the point in saving the interrupt status in `flags'? If the
> caller _wants_ interrupt status preserved then the caller is buggy,
> because schedule() enables interrupts. 2.2 does the same thing.
>
> So this has been changed to:
>
> spin_lock_irq(lock);
> spin_unlock(lock);
> schedule();
> spin_lock(lock);
> spin_unlock_irq(lock);
>
> Or did I miss something?
I'm a bit nervous about changing the old compatibility cruft, but the
above is probably ok.
Anyway, I'd like you to get rid of the global SMP_KERNEL thing (turning it
into a local one if you want to for this case), _and_ I'd like to see this
patch with the wait-queue spinlock _outside_ the __common_wakeup() path.
Why? Those semaphores will eventually want to re-use the wait-queue
spinlock as a per-semaphore spinlock, and they would need to call
__common_wakeup() with the spinlock held to do so. So let's get the
infrastructure in place.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 21:00:11 EST