Jamie Lokier writes:
> kumon@flab.fujitsu.co.jp wrote:
> > 1. run the bh_handler on the initial CPU.
> > 2. return the collected memory to the original slab-cache.
> >
> > Does anybody have ideas?
>
> 3. Provide a kfree_from_cpu function which specific code such as the
> network buffer handlers can call. A short term solution at least.
>
> But the real solution:
>
> The initial data is usually transferred by DMA into central memory --
> it's not in anyone's L1 or L2 cache. Only the header is read by the
It is true but the header has also the same problem.
Measurement shows sk_buf_head produces a next to the worst cache miss-hits
when it is returned to a per-cpu skb pool at kfree_skbmem().
At the function, the header is initialized (zero cleared) and push
onto the pool.
The initialization should not be there.
> So ideally, the copy should be done just before waking up the task
> that's waiting for that read() to complete, and on the same CPU.
In packet reading case, the preferred CPU is always the CPU which
issues read(). Because relevant data is on the cache.
> stack into process context. That's already been proposed for 2.5 as it
> has other advantages. Or, keeping the stack in BH, do the copy there
> and when waking up a process that's waiting on socket read(), set that
Is there 2.5 TODO list somewhere?
-- Computer Systems Laboratory, Fujitsu Labs. kumon@flab.fujitsu.co.jp- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST