All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kasper Sandberg <lkml@metanurb.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bart Van Assche <bart.vanassche@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.26-rc2
Date: Tue, 13 May 2008 01:22:27 +0200	[thread overview]
Message-ID: <1210634547.1093.1.camel@localhost> (raw)
In-Reply-To: <alpine.LFD.1.10.0805121247080.3019@woody.linux-foundation.org>

On Mon, 2008-05-12 at 12:55 -0700, Linus Torvalds wrote:
> 
> On Mon, 12 May 2008, Bart Van Assche wrote:
> > 
> > Sorry if it's my fault that I do not understand the above message
> > completely. But from the above it's not completely clear to me which
> > kernel versions (2.6.2?.? releases) are affected and which are not
> > affected by the performance and correctness issues due to the
> > interaction between the semaphore implementation and the preemptable
> > BKL.
> 
> No released kernels are affected. It's purely a matter that has happened 
> after 2.6.25. The semaphore simplifcation in -rc1 caused a huge 
> performance regression on some benchmarks, and the fix to that in turn 
> caused a semaphore correctness issue, so I just rolled back to the 
> original BKL code that doesn't have any of those interactions.
> 
> In a historical context, the issues involved would only have happened with 
> CONFIG_PREEMPT_BKL. That config option was made the only one in January, 
> and as a result of these issues, we effectively switched it off.
> 
> So you can *think* of the effect of the changes as having gone from 
> CONFIG_PREEMPT_BKL=y to CONFIG_PREEMPT_BKL=n, even though technically we 
> had removed the actual config option to let people choose (so the config 
> option has basically become a static code change).

uhm.. but .25 doesent have PREEMPT_BKL either.. does that mean its on or
off?

> 
> We may end up having to re-instate the config option due to this. 
> Personally, I hope not. It would be nicer if we could just avoid 
> PREEMPT_BKL entirely. 

you mean avoid preempting the bkl, or avoid having the option to choose
to preempt it, and just always do it?

> 
> (To make things somewhat more confusing, some non-PREEMPT_BKL code has 
> then bitrotted since, so if can actually see latency issues, you might 
> want to try the patch here at the end of this email to see if it fixes 
> the worst of them. "cond_resched()" has regressed since the PREEMPT_BKL 
> config option went away).
> 
> 			Linus
> ---
>  include/linux/sched.h |    7 -------
>  1 files changed, 0 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5a63f2d..75c284f 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2038,17 +2038,10 @@ static inline int need_resched(void)
>   * cond_resched_softirq() will enable bhs before scheduling.
>   */
>  extern int _cond_resched(void);
> -#ifdef CONFIG_PREEMPT
> -static inline int cond_resched(void)
> -{
> -	return 0;
> -}
> -#else
>  static inline int cond_resched(void)
>  {
>  	return _cond_resched();
>  }
> -#endif
>  extern int cond_resched_lock(spinlock_t * lock);
>  extern int cond_resched_softirq(void);
>  static inline int cond_resched_bkl(void)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2008-05-12 23:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-12 14:55 Linux 2.6.26-rc2 Linus Torvalds
2008-05-12 16:26 ` XFS/md/blkdev warning (was Re: Linux 2.6.26-rc2) Alistair John Strachan
2008-05-12 16:40   ` Jens Axboe
2008-05-12 16:47   ` Linus Torvalds
2008-05-12 16:49     ` Jens Axboe
2008-05-13  1:05       ` [PATCH] Remove blkdev warning triggered by using md Neil Brown
2008-05-17 18:22       ` XFS/md/blkdev warning (was Re: Linux 2.6.26-rc2) Alistair John Strachan
2008-05-17 18:37         ` Linus Torvalds
2008-05-17 18:41           ` Linus Torvalds
2008-05-17 20:09           ` Alistair John Strachan
2008-05-17 21:17             ` Linus Torvalds
2008-05-17 23:12               ` Alistair John Strachan
2008-05-17 23:39               ` Christoph Hellwig
2008-05-18 14:12                 ` Alistair John Strachan
2008-05-12 19:32 ` Linux 2.6.26-rc2 Bart Van Assche
2008-05-12 19:55   ` Linus Torvalds
2008-05-12 23:22     ` Kasper Sandberg [this message]
2008-05-13  1:49 ` Oops on -rc2-git1, possibly md_raid1 or xfs related. (Was: Re: Linux 2.6.26-rc2) Kasper Sandberg
2008-05-13  1:55   ` Kasper Sandberg
2008-05-13  2:19   ` Neil Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1210634547.1093.1.camel@localhost \
    --to=lkml@metanurb.dk \
    --cc=bart.vanassche@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.