Subject: Re: [take13 1/3] kevent: Core files.

From: Evgeniy Polyakov <[email-masked]>
Date: Fri, 25 Aug 2006 11:20:08 +0400

On Thu, Aug 24, 2006 at 11:58:59PM -0700, Andrew Morton ([email-masked]) wrote:
> > > > kmalloc is really slow actually - it always shows somewhere on top 
> > > > in profiles and brings noticeble overhead
> > > 
> > > It shouldn't.  Please describe the workload and send the profiles.
> > 
> > epoll based trivial server (accept + sendfile for the same file, about
> > 4k), httperf with big amount of simulateneous connections. 3c59x NIC 
> > (with e1000 there were no ioreads and netif_rx).
> > __alloc_skb calls kmem_cache_alloc() and ___kmalloc().
> > 
> > 16158     1.3681  ioread16
> > 8073      0.6835  ioread32
> > 3485      0.2951  irq_entries_start
> > 3018      0.2555  _spin_lock
> > 2103      0.1781  tcp_v4_rcv
> > 1503      0.1273  sysenter_past_esp
> > 1492      0.1263  netif_rx
> > 1459      0.1235  skb_copy_bits
> > 1422      0.1204  _spin_lock_irqsave
> > 1145      0.0969  ip_route_input
> > 983       0.0832  kmem_cache_free
> > 964       0.0816  __alloc_skb
> > 926       0.0784  common_interrupt
> > 891       0.0754  __do_IRQ
> > 846       0.0716  _read_lock
> > 826       0.0699  __netif_rx_schedule
> > 806       0.0682  __kmalloc
> > 767       0.0649  do_tcp_sendpages
> > 747       0.0632  __copy_to_user_ll
> > 744       0.0630  pskb_expand_head
> > 
> 
> That doesn't look too bad.
> 
> What's that as a percentage of total user+system time?

With e1000 allocations take more time than actual TCP processing, so it
rised some suspicious for me (especially in bulk transfer).
Total time is about 7 times more than system one, user time is much less
than system one (about 20 times less, but test duration was not too
long, so it can vary).

I do not say it is bad, but it is noticeble and should be eliminated
if there are no requirements to have it.

-- 
	Evgeniy Polyakov