On 06/11/2015 11:28 PM, Debabrata Banerjee wrote:
Resend in plaintext, thanks gmail:
It's somewhat an intractable problem to know if compaction will succeed
without trying it,
There are heuristics, but those cannot be perfect by definition. I think
the worse problem here is the extra latency,
On 06/11/2015 11:35 PM, Debabrata Banerjee wrote:
There is no "background" it doesn't matter if this activity happens
synchronously or asynchronously, unless you're sensitive to the
latency on that single operation. If you're driving all your cpu's and
memory hard then this is work that still tak
On Thu, 2015-06-11 at 18:18 -0400, Chris Mason wrote:
> But, is there any fallback to a single page allocation somewhere else?
> If this is the only way to get memory, we might want to add a single
> alloc_page path that won't trigger compaction but is at least able to
> wait for kswapd to make pr
On 06/11/2015 05:22 PM, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 17:16 -0400, Chris Mason wrote:
>> On 06/11/2015 04:48 PM, Eric Dumazet wrote:
>>
>> networking is asking for 32KB, and the MM layer is doing what it can to
>> provide it. Are the gains from getting 32KB contig bigger than the co
Please stop top-posting.
Quote the relevant material you are replying to first, the add your
response commentary afterwards rather than beforehand.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
On Thu, Jun 11, 2015 at 02:56:26PM -0700, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 14:45 -0700, Shaohua Li wrote:
>
> > This is exactly what the patch try to do. Atomic 32k allocation will
> > fail with memory pressure, kswapd is waken up to do compaction and we
> > fallback to 4k.
>
> Read yo
On Thu, 2015-06-11 at 14:45 -0700, Shaohua Li wrote:
> This is exactly what the patch try to do. Atomic 32k allocation will
> fail with memory pressure, kswapd is waken up to do compaction and we
> fallback to 4k.
Read your changelog, then read what you just wrote.
Your changelog said :
'compa
On Thu, Jun 11, 2015 at 02:22:13PM -0700, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 17:16 -0400, Chris Mason wrote:
> > On 06/11/2015 04:48 PM, Eric Dumazet wrote:
> > > On Thu, 2015-06-11 at 13:24 -0700, Shaohua Li wrote:
> > >> We saw excessive memory compaction triggered by skb_page_frag_refil
There is no "background" it doesn't matter if this activity happens
synchronously or asynchronously, unless you're sensitive to the
latency on that single operation. If you're driving all your cpu's and
memory hard then this is work that still takes resources. If there's a
kernel thread with compac
Resend in plaintext, thanks gmail:
It's somewhat an intractable problem to know if compaction will succeed
without trying it, and you can certainly end up in a state where memory is
heavily fragmented, even with compaction running. You can't compact kernel
pages for example, so you can end up in a
On Thu, 2015-06-11 at 17:16 -0400, Chris Mason wrote:
> On 06/11/2015 04:48 PM, Eric Dumazet wrote:
> > On Thu, 2015-06-11 at 13:24 -0700, Shaohua Li wrote:
> >> We saw excessive memory compaction triggered by skb_page_frag_refill.
> >> This causes performance issues. Commit 5640f7685831e0 introduc
On 06/11/2015 04:48 PM, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 13:24 -0700, Shaohua Li wrote:
>> We saw excessive memory compaction triggered by skb_page_frag_refill.
>> This causes performance issues. Commit 5640f7685831e0 introduces the
>> order-3 allocation to improve performance. But memor
On Thu, 2015-06-11 at 13:24 -0700, Shaohua Li wrote:
> We saw excessive memory compaction triggered by skb_page_frag_refill.
> This causes performance issues. Commit 5640f7685831e0 introduces the
> order-3 allocation to improve performance. But memory compaction has
> high overhead. The benefit of
We saw excessive memory compaction triggered by skb_page_frag_refill.
This causes performance issues. Commit 5640f7685831e0 introduces the
order-3 allocation to improve performance. But memory compaction has
high overhead. The benefit of order-3 allocation can't compensate the
overhead of memory co
14 matches
Mail list logo
