Re: [patch] voluntary-preempt-2.6.8-rc3-O5

Linh Dang
2004-08-12T02:56:37Z

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