lkml.org 
[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
From
Date
Lee Revell <rlrevell@joe-job.com> 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
skb.

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


Regards

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

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