On Wed, 14 Apr 2004, Henrik Nordstrom wrote: > On Wed, 14 Apr 2004, Nagendra Singh Tomar wrote: > > > This way we can set the P1 (page containing the header) as cacheable and > > P2 as noncacheable. I know it looks ugly but we can make use of the > > remaining of P1 for some slab. > > Very doubtful about this. You will need very many of these kinds of pages, > and I see it very unlikely the relative huge amounts of leftovers will > find any valuable use elsewhere in the kernel. Basically you increase the > memory usage per skb from about the packet size plus skbuff header to at > minimum 2 pages (1 cacheable, one normal), and I do not think many will > find this acceptable, But maybe? > > You also need to worry about tlb flushing and other negative impacts each > time a new skbuff needs to be allocated / freed. To avoid this TLB flushing my idea is to have a pre-initialized pool of such cacheable+noncacheable pages and then allocate from that pool instead of changing the page attributes, everytime we allocate an SKB. > > Regards > Henrik > -- You have moved the mouse. Windows must be restarted for the changes to take effect. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
