> On Jul 9, 2020, at 9:38 PM, Feng Tang wrote:
>
> Give it a second thought, my previous way has more indents and lines,
> but it is easier to be understood that we have special handling for
> 'write' case. So I would prefer using it.
>
> Thoughts?
I don’t feel it is easier to understand. I
On Thu, Jul 09, 2020 at 10:15:19PM +0800, Feng Tang wrote:
> Hi Qian Cai,
>
> On Thu, Jul 09, 2020 at 09:40:40AM -0400, Qian Cai wrote:
> > > > > Can we change the batch firstly, then sync the global counter, finally
> > > > > change the overcommit policy?
> > > >
> > > > These reorderings are re
Hi Qian Cai,
On Thu, Jul 09, 2020 at 09:40:40AM -0400, Qian Cai wrote:
> > > > Can we change the batch firstly, then sync the global counter, finally
> > > > change the overcommit policy?
> > >
> > > These reorderings are really head scratching :)
> > >
> > > I've thought about this before when
On Thu, Jul 09, 2020 at 12:55:54PM +0800, Feng Tang wrote:
> On Tue, Jul 07, 2020 at 01:41:20PM +0800, Feng Tang wrote:
> > On Tue, Jul 07, 2020 at 12:00:09PM +0800, Huang, Ying wrote:
> > > Feng Tang writes:
> > >
> > > > On Mon, Jul 06, 2020 at 06:34:34AM -0700, Andi Kleen wrote:
> > > >> >
On Tue, Jul 07, 2020 at 01:41:20PM +0800, Feng Tang wrote:
> On Tue, Jul 07, 2020 at 12:00:09PM +0800, Huang, Ying wrote:
> > Feng Tang writes:
> >
> > > On Mon, Jul 06, 2020 at 06:34:34AM -0700, Andi Kleen wrote:
> > >> >ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > >
On Tue 07-07-20 09:04:36, Qian Cai wrote:
> On Tue, Jul 07, 2020 at 02:06:19PM +0200, Michal Hocko wrote:
> > On Tue 07-07-20 07:43:48, Qian Cai wrote:
> > >
> > >
> > > > On Jul 7, 2020, at 6:28 AM, Michal Hocko wrote:
> > > >
> > > > Would you have any examples? Because I find this highly unl
On Tue, Jul 07, 2020 at 02:06:19PM +0200, Michal Hocko wrote:
> On Tue 07-07-20 07:43:48, Qian Cai wrote:
> >
> >
> > > On Jul 7, 2020, at 6:28 AM, Michal Hocko wrote:
> > >
> > > Would you have any examples? Because I find this highly unlikely.
> > > OVERCOMMIT_NEVER only works when virtual me
On Tue 07-07-20 07:43:48, Qian Cai wrote:
>
>
> > On Jul 7, 2020, at 6:28 AM, Michal Hocko wrote:
> >
> > Would you have any examples? Because I find this highly unlikely.
> > OVERCOMMIT_NEVER only works when virtual memory is not largerly
> > overcommited wrt to real memory demand. And that te
> On Jul 7, 2020, at 6:28 AM, Michal Hocko wrote:
>
> Would you have any examples? Because I find this highly unlikely.
> OVERCOMMIT_NEVER only works when virtual memory is not largerly
> overcommited wrt to real memory demand. And that tends to be more of
> an exception rather than a rule. "M
On Sun 05-07-20 11:52:32, Qian Cai wrote:
> On Sun, Jul 05, 2020 at 08:58:54PM +0800, Feng Tang wrote:
> > On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote:
> > >
> > >
> > > > On Jul 5, 2020, at 12:45 AM, Feng Tang wrote:
> > > >
> > > > I did reproduce the problem, and from the debugg
On Tue, Jul 07, 2020 at 12:00:09PM +0800, Huang, Ying wrote:
> Feng Tang writes:
>
> > On Mon, Jul 06, 2020 at 06:34:34AM -0700, Andi Kleen wrote:
> >> > ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> >> > -if (ret == 0 && write)
> >> > +if (ret == 0 && w
Feng Tang writes:
> On Mon, Jul 06, 2020 at 06:34:34AM -0700, Andi Kleen wrote:
>> >ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
>> > - if (ret == 0 && write)
>> > + if (ret == 0 && write) {
>> > + if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
>> > +
On Tue, Jul 07, 2020 at 01:06:51AM +, Dennis Zhou wrote:
> On Mon, Jul 06, 2020 at 09:24:43PM +0800, Feng Tang wrote:
> > Hi All,
> >
> > Please help to review this fix patch, thanks!
> >
> > It is against today's linux-mm tree. For easy review, I put the fix
> > into one patch, and I could s
On Mon, Jul 06, 2020 at 06:34:34AM -0700, Andi Kleen wrote:
> > ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > - if (ret == 0 && write)
> > + if (ret == 0 && write) {
> > + if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
> > + schedule_on_eac
On Mon, Jul 06, 2020 at 09:24:43PM +0800, Feng Tang wrote:
> Hi All,
>
> Please help to review this fix patch, thanks!
>
> It is against today's linux-mm tree. For easy review, I put the fix
> into one patch, and I could split it to 2 parts for percpu-counter
> and mm/util.c if it's preferred.
>
On Mon, 6 Jul 2020 06:34:34 -0700 Andi Kleen wrote:
> > ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > - if (ret == 0 && write)
> > + if (ret == 0 && write) {
> > + if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
> > + schedule_on_each_cpu(
> ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> - if (ret == 0 && write)
> + if (ret == 0 && write) {
> + if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
> + schedule_on_each_cpu(sync_overcommit_as);
The schedule_on_each_cpu is not
Hi All,
Please help to review this fix patch, thanks!
It is against today's linux-mm tree. For easy review, I put the fix
into one patch, and I could split it to 2 parts for percpu-counter
and mm/util.c if it's preferred.
>From 593f9dc139181a7c3bb1705aacd1f625f400e458 Mon Sep 17 00:00:00 2001
Fr
On Mon, Jul 06, 2020 at 09:43:13AM +0800, Feng Tang wrote:
> On Sun, Jul 05, 2020 at 11:52:32AM -0400, Qian Cai wrote:
> > On Sun, Jul 05, 2020 at 08:58:54PM +0800, Feng Tang wrote:
> > > On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote:
> > > >
> > > >
> > > > > On Jul 5, 2020, at 12:45
On Sun, Jul 05, 2020 at 11:52:32AM -0400, Qian Cai wrote:
> On Sun, Jul 05, 2020 at 08:58:54PM +0800, Feng Tang wrote:
> > On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote:
> > >
> > >
> > > > On Jul 5, 2020, at 12:45 AM, Feng Tang wrote:
> > > >
> > > > I did reproduce the problem, and
On Sun, Jul 05, 2020 at 08:58:54PM +0800, Feng Tang wrote:
> On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote:
> >
> >
> > > On Jul 5, 2020, at 12:45 AM, Feng Tang wrote:
> > >
> > > I did reproduce the problem, and from the debugging, this should
> > > be the same root cause as
> > >
On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote:
>
>
> > On Jul 5, 2020, at 12:45 AM, Feng Tang wrote:
> >
> > I did reproduce the problem, and from the debugging, this should
> > be the same root cause as lore.kernel.org/lkml/20200526181459.gd...@lca.pw/
> > that loosing the batch cau
> On Jul 5, 2020, at 12:45 AM, Feng Tang wrote:
>
> I did reproduce the problem, and from the debugging, this should
> be the same root cause as lore.kernel.org/lkml/20200526181459.gd...@lca.pw/
> that loosing the batch cause some accuracy problem, and the solution of
> adding some sync is sti
On Thu, Jul 02, 2020 at 03:12:30PM +0800, Feng Tang wrote:
> > <<>>
> > tag=overcommit_memory01 stime=1593425044
> > cmdline="overcommit_memory"
> > contacts=""
> > analysis=exit
> > <<>>
> > tst_test.c:1247: INFO: Timeout per run is 0h 05m 00s
> > overcommit_memory.c:116: INFO: MemTotal is 1639425
On Thu, Jul 02, 2020 at 03:12:30PM +0800, Feng Tang wrote:
> Hi,
>
> On Thu, Jul 02, 2020 at 02:32:01PM +0800, kernel test robot wrote:
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 4e2c82a40911c19419349918e675aa202b113b4d ("[PATCH v5 3/3] mm:
>
Hi,
On Thu, Jul 02, 2020 at 02:32:01PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 4e2c82a40911c19419349918e675aa202b113b4d ("[PATCH v5 3/3] mm: adjust
> vm_committed_as_batch according to vm overcommit policy")
> url:
>
26 matches
Mail list logo
