[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] voluntary-preempt-2.6.8-rc3-O5
Lee Revell <> wrote:

> On Wed, 2004-08-11 at 07:48, Linh Dang wrote:
>> Hi,
>> I'm not running the voluntary-preempt-* patches. but I do see some
>> long latencies with:
>> vanilla 2.6.7+preempt-timing+defer-softirq
>> which were NOT reported here. Is it useful the report them?
> Probably not. Many latency issues as well as bugs in the preempt
> timing patch have been fixed since then. You should try the latest
> version.

which "latest"? Linus's 2.6.8-rcX or Andrew's -mm's or Ingo's patches.

I've looked at Ingo patches but didn't see fixes for the followings:

1. In sys_mount(): do_mount() is called with the BKL held. on jffs2
system, jffs2 might for a big media-scan and lock preemption for
several msecs. even if jffs2_scan_eraseblock() calls cond_resched()
for every flash sector, scanning one sector is still very long.

2. netif_receive_skb(): the rcu_read_lock() is too broad. IMHO, it's
only needed around the 2 list_for_each_entry_rcu()s. There's no
reason why rcu_read_lock() is needed when calling ip_recv on the

3. with Ingo's patches, if all softirqs are done by the daemon then
there's should be NO need to call local_bh_disable()/enable()
around the processing loop in ___do_softirq().

4. in cfi_cmdset_0002.c, using spin_lock_bh() to guard struct flchip
seems to be an overkill. why a semaphore is NOT sufficient?

I'm a total newbie so it's possible that I'm totally wrong about the


Linh Dang
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 14:05    [W:0.322 / U:3.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site