[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinViD=WpwUFUDF6mKbc-Cap_Tg=SXwOjVQ=5u4B@mail.gmail.com>
Date: Wed, 1 Dec 2010 22:16:20 +0800
From: Changli Gao <xiaosuo@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Neil Horman <nhorman@...driver.com>,
"David S. Miller" <davem@...emloft.net>,
Jiri Pirko <jpirko@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] af_packet: use vmalloc_to_page() instead for the
addresss returned by vmalloc()
On Wed, Dec 1, 2010 at 9:38 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le mercredi 01 décembre 2010 à 21:05 +0800, Changli Gao a écrit :
>> On Tue, Nov 30, 2010 at 10:37 PM, Neil Horman <nhorman@...driver.com> wrote:
>> > Off the top of my head, I would think that pgv_to_page could be prototyped such
>> > that it could accept addr, offset and struct page ** arguments. That way we can
>> > track the current page that we're mapped to, lowering the number of calls to
>> > vmalloc_to_page, and we can still use an increment like we do above (as long as
>> > its wrapped in a subsequent call to pgv_to_page)
>>
>> I'll try to optimize pgv_to_page() after this patch series merged. I
>> am planning to call vmalloc_to_page() previously, and cache its result
>> in a per pgv array for future use. Thanks.
>>
>>
>
> Hmm... fact is flush_dcache_page() is void on some arches.
>
> Maybe the only thing to do is avoid pgv_to_page() calls if
> ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE is 0
>
Even then, tpacket_fill_skb() is called for every skb, and
pgv_to_page() is used in it. We have to optimize pgv_to_page().
Thanks.
--
Regards,
Changli Gao(xiaosuo@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists