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

[Linh Dang]

Lee Revell <rlrevell@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/