Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-15 Thread Peter Zijlstra
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 l

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-14 Thread David Rientjes
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, proba

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-02 Thread David Rientjes
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.

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-02 Thread Peter Zijlstra
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 u

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-02 Thread Stephane Eranian
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 k

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-02 Thread Peter Zijlstra
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, s

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-02 Thread Stephane Eranian
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

Re: [patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-07-01 Thread Peter Zijlstra
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 faile

[patch] x86, perf: avoid spamming kernel log for bts buffer failure

2014-06-30 Thread David Rientjes
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, w