Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: > >w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, > >that's only 60% effeciency wrt to memory usage... so, we currently > >waste 40% of memory allocated to mbufs+clusters... Even reducing > >mbufs back to 128 or 256 would be a big help, though IPSEC I believe > >would have issues... > > mbufs are 256 bytes. Hmmm.. I keep getting this confused... maybe because there was discussion about increasing this a few years back... or maybe because NOTES has it as 512.. :) > >Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > >fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > >only issue w/ that would be that a few of the clusters would possibly > >split page boundaries... How much this would effect performance would > >be an interesting question to answer... > > Splitting page boundaries is not an option as it may not be physically > contigous. unless we do something strange like allocate them contigously... though that introduces another set of issues.... > Just don't overengineer the stuff. Mbufs are only used temporarily and > a bit theoretical waste is not much a problem (so far at least). Well, I beg to differ... most gige cards grab mbuf+cluster for every single ring buffer they have.. which is usually 512... so every gige interface for the most part consumes 1meg of memory that is not reusable... because if we run out of mbuf+clusters to replace in the receive ring, we will not tap into the 1meg of mbuf+clusters available to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the fact that we could only use ~65% of that memory, that's a lot of memory wasted... Yeh, everyone says you have gigs of memory, but do we really want to be known as the wasteful OS? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Fri Sep 29 2006 - 21:10:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC