On 05/27/2013 06:25 PM, Eric Dumazet wrote:
On Mon, 2013-05-27 at 13:39 -0400, Rik van Riel wrote:
Yes please. Getting memory management bug reports for
dropped network packets got old years ago. Lets get
rid of those messages.
I am only wondering why this path has anything needing special
On 05/28/2013 12:29 PM, Eric Dumazet wrote:
On Tue, 2013-05-28 at 13:15 -0300, Rafael Aquini wrote:
The real problem seems to be that more and more the network stack (drivers,
perhaps)
is relying on chunks of contiguous page-blocks without a fallback mechanism to
order-0 page allocations. When
On 05/27/2013 06:41 PM, Francois Romieu wrote:
atom...@redhat.com :
[...]
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subsequent retransmit, and an
unnecessary, noisy warning with a kernel backtrace.
These warnings are harmless, but
On Tue, 2013-05-28 at 09:29 -0700, Eric Dumazet wrote:
> I would bump nopage_rs to somethin more reasonable, like one hour or one
> day.
Reasonable is harder to specify but perhaps it could
be made runtime configurable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Tue, 2013-05-28 at 14:43 -0300, Rafael Aquini wrote:
> Perhaps the explanation is because we're looking into old stuff bad effects,
> then. But just to list a few for your appreciation:
>
> Apr 23 11:25:31 217-IDC kernel: httpd: page allo
On Tue, 2013-05-28 at 14:43 -0300, Rafael Aquini wrote:
>
> Perhaps the explanation is because we're looking into old stuff bad effects,
> then. But just to list a few for your appreciation:
>
> ---
On Tue, May 28, 2013 at 09:29:37AM -0700, Eric Dumazet wrote:
> On Tue, 2013-05-28 at 13:15 -0300, Rafael Aquini wrote:
>
> > The real problem seems to be that more and more the network stack (drivers,
> > perhaps)
> > is relying on chunks of contiguous page-blocks without a fallback mechanism
>
On Tue, 2013-05-28 at 09:00 -0700, Ben Greear wrote:
> On 05/27/2013 03:41 PM, Francois Romieu wrote:
> > atom...@redhat.com :
> > [...]
> >> Failed GFP_ATOMIC allocations by the network stack result in dropped
> >> packets, which will be received on a subsequent retransmit, and an
> >> unnecessar
On Tue, May 28, 2013 at 12:31 AM, Joe Perches wrote:
>
> I think the __alloc_skb alloc failure message is ok,
> but maybe there shouldn't be something "scary" like
> a dump_stack.
>
> Maybe this site should use a trivial debug error
> message like below instead.
The stack trace may or may not be
On Tue, 2013-05-28 at 13:15 -0300, Rafael Aquini wrote:
> The real problem seems to be that more and more the network stack (drivers,
> perhaps)
> is relying on chunks of contiguous page-blocks without a fallback mechanism to
> order-0 page allocations. When memory gets fragmented, these alloc fa
On 05/28/2013 09:15 AM, Rafael Aquini wrote:
On Tue, May 28, 2013 at 09:00:45AM -0700, Ben Greear wrote:
On 05/27/2013 03:41 PM, Francois Romieu wrote:
atom...@redhat.com :
[...]
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subseque
On Tue, May 28, 2013 at 09:00:45AM -0700, Ben Greear wrote:
> On 05/27/2013 03:41 PM, Francois Romieu wrote:
> >atom...@redhat.com :
> >[...]
> >>Failed GFP_ATOMIC allocations by the network stack result in dropped
> >>packets, which will be received on a subsequent retransmit, and an
> >>unnecess
On 05/27/2013 03:41 PM, Francois Romieu wrote:
atom...@redhat.com :
[...]
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subsequent retransmit, and an
unnecessary, noisy warning with a kernel backtrace.
These warnings are harmless, but
On Mon, 2013-05-27 at 23:04 -0700, Eric Dumazet wrote:
> If dump_stack are scary, they are scary for every k[mz]alloc() users,
> not only __alloc_skb_alloc()
True, but perhaps they are relatively rarer though
for non net use cases.
--
To unsubscribe from this list: send the line "unsubscribe lin
On Mon, 2013-05-27 at 21:31 -0700, Joe Perches wrote:
> I think the __alloc_skb alloc failure message is ok,
> but maybe there shouldn't be something "scary" like
> a dump_stack.
>
> Maybe this site should use a trivial debug error
> message like below instead.
> ---
Oh well.
If dump_stack are
On Mon, 2013-05-27 at 15:25 -0700, Eric Dumazet wrote:
> On Mon, 2013-05-27 at 13:39 -0400, Rik van Riel wrote:
> > On 05/26/2013 04:19 PM, atom...@redhat.com wrote:
> > > Failed GFP_ATOMIC allocations by the network stack result in dropped
> > > packets, which will be received on a subsequent retr
atom...@redhat.com :
[...]
> Failed GFP_ATOMIC allocations by the network stack result in dropped
> packets, which will be received on a subsequent retransmit, and an
> unnecessary, noisy warning with a kernel backtrace.
>
> These warnings are harmless, but they still cause users to panic and
> f
On Mon, 2013-05-27 at 13:39 -0400, Rik van Riel wrote:
> On 05/26/2013 04:19 PM, atom...@redhat.com wrote:
> > From: Aaron Tomlin
> >
> > Since v1:
> > - Removed unnecessary parentheses
> >
> > ---8<---
> >
> > Failed GFP_ATOMIC allocations by the network stack result in dropped
> > packets, whi
On Sun, May 26, 2013 at 09:45:01PM +0100, atom...@redhat.com wrote:
> From: Aaron Tomlin
>
> Since v1:
> - Removed unnecessary parentheses (sergei.shtylyov)
>
> ---8<---
>
> Failed GFP_ATOMIC allocations by the network stack result in dropped
> packets, which will be received on a subsequent r
Hello.
On 27-05-2013 0:19, atom...@redhat.com wrote:
From: Aaron Tomlin
Since v1:
- Removed unnecessary parentheses
The "changes since version X" section should typically go after ---
tearline, else the mainatiner will have to edit your patch before applying.
---8<---
Failed G
On 05/26/2013 04:19 PM, atom...@redhat.com wrote:
From: Aaron Tomlin
Since v1:
- Removed unnecessary parentheses
---8<---
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subsequent retransmit, and an
unnecessary, noisy warning with a
From: Aaron Tomlin
Since v1:
- Removed unnecessary parentheses (sergei.shtylyov)
---8<---
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subsequent retransmit, and an
unnecessary, noisy warning with a kernel backtrace.
These warnings
From: Aaron Tomlin
Since v1:
- Removed unnecessary parentheses
---8<---
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a subsequent retransmit, and an
unnecessary, noisy warning with a kernel backtrace.
These warnings are harmless, but
23 matches
Mail list logo
