Messages in this thread | | | Subject | Re: [patch] voluntary-preempt-2.6.8-rc3-O5 | From | Linh Dang <> | Date | Wed, 11 Aug 2004 22:55:44 -0400 |
| |
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/
| |