On Mon, Jul 14, 2014 at 04:33:47PM -0700, David Rientjes wrote:
> On Mon, 30 Jun 2014, David Rientjes wrote:
>
> > It's unnecessary to excessively spam the kernel log anytime the BTS buffer
> > cannot be allocated, so make this allocation __GFP_NOWARN.
> >
> > The user probably will want to at
On Mon, Jul 14, 2014 at 04:33:47PM -0700, David Rientjes wrote:
On Mon, 30 Jun 2014, David Rientjes wrote:
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be allocated, so make this allocation __GFP_NOWARN.
The user probably will want to at least find
On Mon, 30 Jun 2014, David Rientjes wrote:
> It's unnecessary to excessively spam the kernel log anytime the BTS buffer
> cannot be allocated, so make this allocation __GFP_NOWARN.
>
> The user probably will want to at least find some artifact that the
> allocation has failed in the past,
On Mon, 30 Jun 2014, David Rientjes wrote:
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be allocated, so make this allocation __GFP_NOWARN.
The user probably will want to at least find some artifact that the
allocation has failed in the past, probably
On Wed, 2 Jul 2014, Peter Zijlstra wrote:
> > David and I discussed this. He can probably add more background
> > info, if needed.
>
> It would still be good to see why compaction etc is failing.
>
"Why compaction is failing" has been the story of my life for the past few
weeks,
On Wed, Jul 02, 2014 at 03:38:50PM +0200, Stephane Eranian wrote:
> On Wed, Jul 2, 2014 at 3:31 PM, Peter Zijlstra wrote:
> > Right, that'd suck. I suppose we could also change that to allocate the
> > DS resources on first demand and never free them again.
> >
> Some may argue that if you never
On Wed, Jul 2, 2014 at 3:31 PM, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 03:16:40PM +0200, Stephane Eranian wrote:
>> On Tue, Jul 1, 2014 at 11:34 AM, Peter Zijlstra wrote:
>> > On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
>> >> It's unnecessary to excessively spam the
On Wed, Jul 02, 2014 at 03:16:40PM +0200, Stephane Eranian wrote:
> On Tue, Jul 1, 2014 at 11:34 AM, Peter Zijlstra wrote:
> > On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
> >> It's unnecessary to excessively spam the kernel log anytime the BTS buffer
> >> cannot be allocated,
On Tue, Jul 1, 2014 at 11:34 AM, Peter Zijlstra wrote:
> On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
>> It's unnecessary to excessively spam the kernel log anytime the BTS buffer
>> cannot be allocated, so make this allocation __GFP_NOWARN.
>>
>> The user probably will want to
On Tue, Jul 1, 2014 at 11:34 AM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be allocated, so make this allocation __GFP_NOWARN.
The user probably
On Wed, Jul 02, 2014 at 03:16:40PM +0200, Stephane Eranian wrote:
On Tue, Jul 1, 2014 at 11:34 AM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be
On Wed, Jul 2, 2014 at 3:31 PM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Jul 02, 2014 at 03:16:40PM +0200, Stephane Eranian wrote:
On Tue, Jul 1, 2014 at 11:34 AM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
It's
On Wed, Jul 02, 2014 at 03:38:50PM +0200, Stephane Eranian wrote:
On Wed, Jul 2, 2014 at 3:31 PM, Peter Zijlstra pet...@infradead.org wrote:
Right, that'd suck. I suppose we could also change that to allocate the
DS resources on first demand and never free them again.
Some may argue that
On Wed, 2 Jul 2014, Peter Zijlstra wrote:
David and I discussed this. He can probably add more background
info, if needed.
It would still be good to see why compaction etc is failing.
Why compaction is failing has been the story of my life for the past few
weeks, unfortunately. One
On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
> It's unnecessary to excessively spam the kernel log anytime the BTS buffer
> cannot be allocated, so make this allocation __GFP_NOWARN.
>
> The user probably will want to at least find some artifact that the
> allocation has
On Mon, Jun 30, 2014 at 04:04:08PM -0700, David Rientjes wrote:
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be allocated, so make this allocation __GFP_NOWARN.
The user probably will want to at least find some artifact that the
allocation has failed in
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be allocated, so make this allocation __GFP_NOWARN.
The user probably will want to at least find some artifact that the
allocation has failed in the past, probably due to fragmentation because
of its large size,
It's unnecessary to excessively spam the kernel log anytime the BTS buffer
cannot be allocated, so make this allocation __GFP_NOWARN.
The user probably will want to at least find some artifact that the
allocation has failed in the past, probably due to fragmentation because
of its large size,
18 matches
Mail list logo
