On 09/06/2017 04:32 PM, Andrew Jeffery wrote:
Guess I need to dig up my eval board and see if I can reproduce the problem.
Seems you are saying that the problem is always seen when issuing a sequence
of "clear faults" commands on multiple pages ?
Yeah. We're also seeing bad behaviour under
On Wed, 6 Sep 2017, David Rientjes wrote:
> > The oom_kill_allocating_task sysctl which causes the OOM killer
> > to simple kill the allocating task is useless. Killing the random
> > task is not the best idea.
> >
> > Nobody likes it, and hopefully nobody uses it.
> > We want to completely deprec
On Thu, Sep 07, 2017 at 09:43:30AM -0500, Christopher Lameter wrote:
> On Wed, 6 Sep 2017, David Rientjes wrote:
>
> > > The oom_kill_allocating_task sysctl which causes the OOM killer
> > > to simple kill the allocating task is useless. Killing the random
> > > task is not the best idea.
> > >
>
On Thu, 7 Sep 2017, Roman Gushchin wrote:
> > Really? From what I know and worked on way back when: The reason was to be
> > able to contain the affected application in a cpuset. Multiple apps may
> > have been running in multiple cpusets on a large NUMA machine and the OOM
> > condition in one cp
On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:
> On 09/06/2017 04:32 PM, Andrew Jeffery wrote:
>
> > >
> > > Guess I need to dig up my eval board and see if I can reproduce the
> > > problem.
> > > Seems you are saying that the problem is always seen when issuing a
> > > sequence
> >
On Wed, Sep 06, 2017 at 10:28:59AM +0200, Michal Hocko wrote:
> On Tue 05-09-17 17:53:44, Johannes Weiner wrote:
> > The cgroup-awareness in the OOM killer is exactly the same thing. It
> > should have been the default from the beginning, because the user
> > configures a group of tasks to be an in
On Mon, 4 Sep 2017, Roman Gushchin wrote
> To address these issues, cgroup-aware OOM killer is introduced.
You are missing a major issue here. Processes may have allocation
constraints to memory nodes, special DMA zones etc etc. OOM conditions on
such resource constricted allocations need to be d
On Tue, 5 Sep 2017, Michal Hocko wrote:
> I would argue that we should simply deprecate and later drop the sysctl.
> I _strongly_ suspect anybody is using this. If yes it is not that hard
> to change the kernel command like rather than select the sysctl. The
> deprecation process would be
>
On Wed, 6 Sep 2017, Michal Hocko wrote:
> I am not sure this is how things evolved actually. This is way before
> my time so my git log interpretation might be imprecise. We do have
> oom_badness heuristic since out_of_memory has been introduced and
> oom_kill_allocating_task has been introduced m
On Thu, Sep 07, 2017 at 10:03:24AM -0500, Christopher Lameter wrote:
> On Thu, 7 Sep 2017, Roman Gushchin wrote:
>
> > > Really? From what I know and worked on way back when: The reason was to be
> > > able to contain the affected application in a cpuset. Multiple apps may
> > > have been running
On Thu, 7 Sep 2017, Roman Gushchin wrote:
> On Thu, Sep 07, 2017 at 10:03:24AM -0500, Christopher Lameter wrote:
> > On Thu, 7 Sep 2017, Roman Gushchin wrote:
> >
> > > > Really? From what I know and worked on way back when: The reason was to
> > > > be
> > > > able to contain the affected applic
On Thu, 7 Sep 2017, Christopher Lameter wrote:
> > SGI required it when it was introduced simply to avoid the very expensive
> > tasklist scan. Adding Christoph Lameter to the cc since he was involved
> > back then.
>
> Really? From what I know and worked on way back when: The reason was to be
>
On Thu, 7 Sep 2017, Christopher Lameter wrote:
> > I am not sure this is how things evolved actually. This is way before
> > my time so my git log interpretation might be imprecise. We do have
> > oom_badness heuristic since out_of_memory has been introduced and
> > oom_kill_allocating_task has be
On 09/07/2017 08:22 AM, Andrew Jeffery wrote:
On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:
On 09/06/2017 04:32 PM, Andrew Jeffery wrote:
Guess I need to dig up my eval board and see if I can reproduce the problem.
Seems you are saying that the problem is always seen when issuing
On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:
> On 09/07/2017 08:22 AM, Andrew Jeffery wrote:
> > On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:
> > > On 09/06/2017 04:32 PM, Andrew Jeffery wrote:
> > >
> > > > >
> > > > > Guess I need to dig up my eval board and see if I ca
On 09/07/2017 06:02 PM, Andrew Jeffery wrote:
On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:
On 09/07/2017 08:22 AM, Andrew Jeffery wrote:
On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:
On 09/06/2017 04:32 PM, Andrew Jeffery wrote:
Guess I need to dig up my eval board a
On Thu, 2017-09-07 at 18:26 -0700, Guenter Roeck wrote:
> On 09/07/2017 06:02 PM, Andrew Jeffery wrote:
> > On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:
> > > On 09/07/2017 08:22 AM, Andrew Jeffery wrote:
> > > > On Thu, 2017-09-07 at 06:40 -0700, Guenter Roeck wrote:
> > > > > On 09/06/
On 09/07/2017 07:06 PM, Andrew Jeffery wrote:
On Thu, 2017-09-07 at 18:26 -0700, Guenter Roeck wrote:
On 09/07/2017 06:02 PM, Andrew Jeffery wrote:
On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:
On 09/07/2017 08:22 AM, Andrew Jeffery wrote:
On Thu, 2017-09-07 at 06:40 -0700, Guenter
On Thu, 2017-09-07 at 19:17 -0700, Guenter Roeck wrote:
> On 09/07/2017 07:06 PM, Andrew Jeffery wrote:
> > On Thu, 2017-09-07 at 18:26 -0700, Guenter Roeck wrote:
> > > On 09/07/2017 06:02 PM, Andrew Jeffery wrote:
> > > > On Thu, 2017-09-07 at 17:27 -0700, Guenter Roeck wrote:
> > > > > On 09/07/
On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:
> > I can't test with devicetree. x86 system.
> >
> > 2,100+ iterations with your driver, no failures.
>
> Great. I really appreciate your testing here, so thanks for your
> efforts. I owe you a few drinks if we ever happen to meet.
Actual
On 09/07/2017 08:40 PM, Andrew Jeffery wrote:
On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:
I can't test with devicetree. x86 system.
2,100+ iterations with your driver, no failures.
Great. I really appreciate your testing here, so thanks for your
efforts. I owe you a few drinks
On Thu, 2017-09-07 at 21:43 -0700, Guenter Roeck wrote:
> On 09/07/2017 08:40 PM, Andrew Jeffery wrote:
> > On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:
> > > > I can't test with devicetree. x86 system.
> > > >
> > > > 2,100+ iterations with your driver, no failures.
> > >
> > > Gre
On 09/07/2017 08:40 PM, Andrew Jeffery wrote:
On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:
I can't test with devicetree. x86 system.
2,100+ iterations with your driver, no failures.
Great. I really appreciate your testing here, so thanks for your
efforts. I owe you a few drinks
On Thu, 2017-09-07 at 22:14 -0700, Guenter Roeck wrote:
> On 09/07/2017 08:40 PM, Andrew Jeffery wrote:
> > On Fri, 2017-09-08 at 12:51 +1000, Andrew Jeffery wrote:
> > > > I can't test with devicetree. x86 system.
> > > >
> > > > 2,100+ iterations with your driver, no failures.
> > >
> > > Gre
Hi Linus,
Very sorry that I had not responded quickly.
When I was digging into tool version dependency,
as you pointed out, gperf is a problem (but seemed one time breakage
for gperf 3.1)
flex seemed very stable for a long time.
bison seemed a bit problem if old version is used.
But, I did not
25 matches
Mail list logo
