Eric Dumazet wrote: > Herbert Xu a écrit : >> However, I'm still a little concerned about the effect of two more >> atomic op's per packet that we're adding here. Hang on a sec, that >> should've been Dave's line since atomic ops are cheap on x86 :) >> >> But seriously, it's not so much that we have two more atomic op's >> per packet, but we have two more writes to a single global counter >> for each packet. This is going to really suck on SMP. >> >> So what I'd like to see is a scheme that's similar to sk_forward_alloc. >> The idea is that each socket allocates memory using mem_schedule and >> then stores it in sk_forward_alloc. Each packet then only has to >> add to/subtract from sk_forward_alloc. >> >> There is one big problem with this though, UDP is not serialised like >> TCP. So you can't just use sk_forward_alloc since it's not an atomic_t. >> >> We'll need to think about this one a bit more. > > I agree adding yet another atomics ops is a big problem. > > Another idea, coupled with recent work on percpu storage done by > Christoph Lameter, would be to use kind of a percpu_counter : > > We dont really need strong and precise memory accounting (UDP , but TCP > as well), just some kind of limit to avoid memory to be too much used. > > That is, updating a percpu variable, and doing some updates to a global > counter only when this percpu variable escapes from a given range. > > Lot of contended cache lines could benefit from this relaxing (count of > sockets...) > > I would wait first that Christoph work is done, so that we dont need > atomic ops on local cpu storage (and no need to disable preemption too).
Thank you for your comments. I understood your concern of atomic operations. Let me try to use sk_forward_alloc at first, while percpu storage is an interesting idea. Many thanks, Hideo -- Hitachi Computer Products (America) Inc. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
