together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc
together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc
together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc
together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc
, but also made high memory available via
memblock allocation which does not work together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike
does not work together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
does not work together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
does not work together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
and can lead to kernel panic.
This changes back to only low memory being allocatable in the early
stages, now using memblock allocation.
Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
arch/sparc/mm/init_32.c | 3 +++
1
Commit cca079ef8ac29a7c02192d2bad2ffe4c0c5ffdd0 changed sparc32 to use
memblocks instead of bootmem, but also made high memory available via
memblock allocation which does not work together with e.g. phys_to_virt
and can lead to kernel panic.
This changes back to only low memory being allocatable
d
> leads to crashes.
>
> This changes back to only low memory being allocatable in the early
> stages, now using memblock allocation.
>
> Signed-off-by: Andreas Larsson
Acked-by: Mike Rapoport
> ---
> arch/sparc/mm/init_32.c | 3 +++
> 1 file changed, 3 insertions(+)
>
Commit cca079ef8ac29a7c02192d2bad2ffe4c0c5ffdd0 changed sparc32 to use
memblocks instead of bootmem, but also made high memory available via
memblock allocation which does work together with e.g. phys_to_virt and
leads to crashes.
This changes back to only low memory being allocatable
From: Gao Xiang
Try to forcely switch to inplace I/O under low memory scenario in
order to avoid direct memory reclaim due to cached page allocation.
Reviewed-by: Chao Yu
Signed-off-by: Gao Xiang
---
v2:
refine the gfp definition.
fs/erofs/compress.h | 3 +++
fs/erofs/zdata.c| 48
Hi Chao,
On Wed, Dec 09, 2020 at 06:07:08PM +0800, Chao Yu wrote:
> On 2020/12/8 13:46, Gao Xiang wrote:
...
> > bool standalone = true;
> > + gfp_t gfp = mapping_gfp_constraint(mc, GFP_KERNEL) &
> > ~__GFP_DIRECT_RECLAIM;
>
> Could be local as there is only one place uses it.
This
On 2020/12/8 13:46, Gao Xiang wrote:
From: Gao Xiang
Try to forcely switch to inplace I/O under low memory scenario in
order to avoid direct memory reclaim due to cached page allocation.
Signed-off-by: Gao Xiang
---
This was commercially used internally for years, but due to customized
page
From: Gao Xiang
Try to forcely switch to inplace I/O under low memory scenario in
order to avoid direct memory reclaim due to cached page allocation.
Signed-off-by: Gao Xiang
---
This was commercially used internally for years, but due to customized
page->mapping before, it cannot clea
Zhou wrote:
>>>>> Add documentation for DT property used by arm64 kdump:
>>>>> linux,low-memory-range.
>>>>> "linux,low-memory-range" is an another memory region used for crash
>>>>> dump kernel devices.
>>>>> di
Hi guys,
On 26/05/2020 22:18, Rob Herring wrote:
> On Fri, May 22, 2020 at 11:24:11AM +0800, chenzhou wrote:
>> On 2020/5/21 21:29, Rob Herring wrote:
>>> On Thu, May 21, 2020 at 3:35 AM Chen Zhou wrote:
>>>> Add documentation for DT property used by arm64 kdum
m64 kdump:
> >> linux,low-memory-range.
> >> "linux,low-memory-range" is an another memory region used for crash
> >> dump kernel devices.
> >>
> >> Signed-off-by: Chen Zhou
> >> ---
> >> Documentation/devicetree/bindings
Hi Rob,
On 2020/5/21 21:29, Rob Herring wrote:
> On Thu, May 21, 2020 at 3:35 AM Chen Zhou wrote:
>> Add documentation for DT property used by arm64 kdump:
>> linux,low-memory-range.
>> "linux,low-memory-range" is an another memory region used for crash
>>
On Thu, May 21, 2020 at 3:35 AM Chen Zhou wrote:
>
> Add documentation for DT property used by arm64 kdump:
> linux,low-memory-range.
> "linux,low-memory-range" is an another memory region used for crash
> dump kernel devices.
>
> Signed-off-by: Chen Zhou
&g
Add documentation for DT property used by arm64 kdump:
linux,low-memory-range.
"linux,low-memory-range" is an another memory region used for crash
dump kernel devices.
Signed-off-by: Chen Zhou
---
Documentation/devicetree/bindings/chosen.txt | 25
1 file c
If we want to reserve crashkernel above 4G, we could use parameters
"crashkernel=X crashkernel=Y,low", in this case, specified size low
memory is reserved for crash dump kernel devices and never mapped by
the first kernel. This memory range is advertised to crash dump kernel
via DT prop
Hi!
> >
> > And if there is a meaningful way to make the kernel behave better, that
> > would
> > obviously be of huge value too.
> >
> > Thanks
> > Daniel
>
> Hi,
>
> Is there a way for an application to be told that there is a memory
> pressure situation?
> For example, say I do a "make
On Wed 21-08-19 22:42:29, James Courtier-Dutton wrote:
> On Tue, 20 Aug 2019 at 07:47, Daniel Drake wrote:
> >
> > Hi,
> >
> > And if there is a meaningful way to make the kernel behave better, that
> > would
> > obviously be of huge value too.
> >
> > Thanks
> > Daniel
>
> Hi,
>
> Is there a
On Fri, Aug 23, 2019 at 9:54 AM ndrw wrote:
> That's obviously a lot better than hard freezes but I wouldn't call such
> system lock-ups an excellent result. PSI-triggered OOM killer would have
> indeed been very useful as an emergency brake, and IMHO such mechanism
> should be built in the
On 20/08/2019 07:46, Daniel Drake wrote:
To share our results so far, despite this daemon being a quick initial
implementation, we find that it is bringing excellent results, no more memory
pressure hangs. The system recovers in less than 30 seconds, usually in more
like 10-15 seconds.
That's
On Tue, 20 Aug 2019 at 07:47, Daniel Drake wrote:
>
> Hi,
>
> And if there is a meaningful way to make the kernel behave better, that would
> obviously be of huge value too.
>
> Thanks
> Daniel
Hi,
Is there a way for an application to be told that there is a memory
pressure situation?
For
loyed as a standard part
of the Linux desktop.
https://gitlab.freedesktop.org/hadess/low-memory-monitor/
And if there is a meaningful way to make the kernel behave better, that would
obviously be of huge value too.
Thanks
Daniel
On 8/9/19 7:31 PM, Johannes Weiner wrote:
>> It made a difference, but not enough, it seems. Before the patch I could
>> observe "io:full avg10" around 75% and "memory:full avg10" around 20%,
>> after the patch, "memory:full avg10" went to around 45%, while io stayed
>> the same (BTW should the
On Sat 10-08-19 13:34:06, ndrw wrote:
> On 09/08/2019 11:50, Michal Hocko wrote:
> > We try to protect low amount of cache. Have a look at get_scan_count
> > function. But the exact amount of the cache to be protected is really
> > hard to know wihtout a crystal ball or understanding of the
On 09/08/2019 09:57, Michal Hocko wrote:
This is a useful feedback! What was your workload? Which kernel version?
With 16GB zram swap and swappiness=60 I get the avg10 memory PSI numbers
of about 10 when swap is half filled and ~30 immediately before the
freeze. Swapping with zram has less
On 09/08/2019 11:50, Michal Hocko wrote:
We try to protect low amount of cache. Have a look at get_scan_count
function. But the exact amount of the cache to be protected is really
hard to know wihtout a crystal ball or understanding of the workload.
The kernel doesn't have neither of the two.
On Fri, Aug 09, 2019 at 04:56:28PM +0200, Vlastimil Babka wrote:
> On 8/8/19 7:27 PM, Johannes Weiner wrote:
> > On Thu, Aug 08, 2019 at 04:47:18PM +0200, Vlastimil Babka wrote:
> >> On 8/7/19 10:51 PM, Johannes Weiner wrote:
> >>> From 9efda85451062dea4ea287a886e515efefeb1545 Mon Sep 17 00:00:00
On 8/8/19 7:27 PM, Johannes Weiner wrote:
> On Thu, Aug 08, 2019 at 04:47:18PM +0200, Vlastimil Babka wrote:
>> On 8/7/19 10:51 PM, Johannes Weiner wrote:
>>> From 9efda85451062dea4ea287a886e515efefeb1545 Mon Sep 17 00:00:00 2001
>>> From: Johannes Weiner
>>> Date: Mon, 5 Aug 2019 13:15:16 -0400
[...]
Hi,
This is an interesting topic for me so I would like to join the conversation.
I will be glad if I can be of any help here either in testing PSI, or
verifying some scenarios and observation.
I have some experience working with low memory embedded devices, like
RAM as low as 128MB
On Fri 09-08-19 11:09:33, ndrw wrote:
> On 09/08/2019 09:57, Michal Hocko wrote:
> > We already do have a reserve (min_free_kbytes). That gives kswapd some
> > room to perform reclaim in the background without obvious latencies to
> > allocating tasks (well CPU still be used so there is still some
On 09/08/2019 09:57, Michal Hocko wrote:
We already do have a reserve (min_free_kbytes). That gives kswapd some
room to perform reclaim in the background without obvious latencies to
allocating tasks (well CPU still be used so there is still some effect).
I tried this option in the past.
On Thu 08-08-19 22:59:32, ndrw wrote:
> On 08/08/2019 19:59, Michal Hocko wrote:
> > Well, I am afraid that implementing anything like that in the kernel
> > will lead to many regressions and bug reports. People tend to have very
> > different opinions on when it is suitable to kill a potentially
On 08/08/2019 19:59, Michal Hocko wrote:
Well, I am afraid that implementing anything like that in the kernel
will lead to many regressions and bug reports. People tend to have very
different opinions on when it is suitable to kill a potentially
important part of a workload just because memory
On Thu 08-08-19 18:57:02, ndrw...@redhazel.co.uk wrote:
>
>
> On 8 August 2019 17:32:28 BST, Michal Hocko wrote:
> >
> >> Would it be possible to reserve a fixed (configurable) amount of RAM
> >for caches,
> >
> >I am afraid there is nothing like that available and I would even argue
> >it
On 8 August 2019 17:32:28 BST, Michal Hocko wrote:
>
>> Would it be possible to reserve a fixed (configurable) amount of RAM
>for caches,
>
>I am afraid there is nothing like that available and I would even argue
>it doesn't make much sense either. What would you consider to be a
>cache? A
On Thu, Aug 08, 2019 at 04:47:18PM +0200, Vlastimil Babka wrote:
> On 8/7/19 10:51 PM, Johannes Weiner wrote:
> > From 9efda85451062dea4ea287a886e515efefeb1545 Mon Sep 17 00:00:00 2001
> > From: Johannes Weiner
> > Date: Mon, 5 Aug 2019 13:15:16 -0400
> > Subject: [PATCH] psi: trigger the OOM
On Thu 08-08-19 16:10:07, ndrw...@redhazel.co.uk wrote:
>
>
> On 8 August 2019 12:48:26 BST, Michal Hocko wrote:
> >>
> >> Per default, the OOM killer will engage after 15 seconds of at least
> >> 80% memory pressure. These values are tunable via sysctls
> >> vm.thrashing_oom_period and
On 8 August 2019 12:48:26 BST, Michal Hocko wrote:
>>
>> Per default, the OOM killer will engage after 15 seconds of at least
>> 80% memory pressure. These values are tunable via sysctls
>> vm.thrashing_oom_period and vm.thrashing_oom_level.
>
>As I've said earlier I would be somehow more
On 8/7/19 10:51 PM, Johannes Weiner wrote:
> From 9efda85451062dea4ea287a886e515efefeb1545 Mon Sep 17 00:00:00 2001
> From: Johannes Weiner
> Date: Mon, 5 Aug 2019 13:15:16 -0400
> Subject: [PATCH] psi: trigger the OOM killer on severe thrashing
Thanks a lot, perhaps finally we are going to eat
On Wed 07-08-19 16:51:38, Johannes Weiner wrote:
[...]
> >From 9efda85451062dea4ea287a886e515efefeb1545 Mon Sep 17 00:00:00 2001
> From: Johannes Weiner
> Date: Mon, 5 Aug 2019 13:15:16 -0400
> Subject: [PATCH] psi: trigger the OOM killer on severe thrashing
>
> Over the last few years we have
On Wed, Aug 07, 2019 at 02:01:30PM -0700, Andrew Morton wrote:
> On Wed, 7 Aug 2019 16:51:38 -0400 Johannes Weiner wrote:
>
> > However, eb414681d5a0 ("psi: pressure stall information for CPU,
> > memory, and IO") introduced a memory pressure metric that quantifies
> > the share of wallclock
On Wed, Aug 07, 2019 at 04:51:42PM -0400, Johannes Weiner wrote:
> Per default, the OOM killer will engage after 15 seconds of at least
> 80% memory pressure. These values are tunable via sysctls
> vm.thrashing_oom_period and vm.thrashing_oom_level.
Let's go with this:
Per default, the OOM
On Wed, 7 Aug 2019 16:51:38 -0400 Johannes Weiner wrote:
> However, eb414681d5a0 ("psi: pressure stall information for CPU,
> memory, and IO") introduced a memory pressure metric that quantifies
> the share of wallclock time in which userspace waits on reclaim,
> refaults, swapins. By using
On Wed, Aug 07, 2019 at 09:59:27AM +0200, Michal Hocko wrote:
> On Tue 06-08-19 18:01:50, Johannes Weiner wrote:
> > On Tue, Aug 06, 2019 at 09:27:05AM -0700, Suren Baghdasaryan wrote:
> [...]
> > > > > I'm not sure 10s is the perfect value here, but I do think the kernel
> > > > > should try to
On Tue 06-08-19 18:01:50, Johannes Weiner wrote:
> On Tue, Aug 06, 2019 at 09:27:05AM -0700, Suren Baghdasaryan wrote:
[...]
> > > > I'm not sure 10s is the perfect value here, but I do think the kernel
> > > > should try to get out of such a state, where interacting with the
> > > > system is
On Tue, Aug 06, 2019 at 09:27:05AM -0700, Suren Baghdasaryan wrote:
> On Tue, Aug 6, 2019 at 7:36 AM Michal Hocko wrote:
> >
> > On Tue 06-08-19 10:27:28, Johannes Weiner wrote:
> > > On Tue, Aug 06, 2019 at 11:36:48AM +0200, Vlastimil Babka wrote:
> > > > On 8/6/19 3:08 AM, Suren Baghdasaryan
On Tue, 6 Aug 2019 at 02:09, Suren Baghdasaryan wrote:
>
> 80% of the last 10 seconds spent in full stall would definitely be a
> problem. If the system was already low on memory (which it probably
> is, or we would not be reclaiming so hard and registering such a big
> stall) then oom-killer
Sorry, I don't have the original message to reply to.. But to those
interested, I have found a solution to the kernel's complete inability
to allocate more memory when it needs to swap out.
Increase the /proc/sys/vm/watermark_scale_factor from the default 10 to 500
It will make a huge
* Artem S. Tashkinov:
> There's this bug which has been bugging many people for many years
> already and which is reproducible in less than a few minutes under the
> latest and greatest kernel, 5.2.6. All the kernel parameters are set to
> defaults.
>
> Steps to reproduce:
>
> 1) Boot with mem=4G
On Tue, Aug 6, 2019 at 7:36 AM Michal Hocko wrote:
>
> On Tue 06-08-19 10:27:28, Johannes Weiner wrote:
> > On Tue, Aug 06, 2019 at 11:36:48AM +0200, Vlastimil Babka wrote:
> > > On 8/6/19 3:08 AM, Suren Baghdasaryan wrote:
> > > >> @@ -1280,3 +1285,50 @@ static int __init psi_proc_init(void)
> >
On Tue 06-08-19 10:27:28, Johannes Weiner wrote:
> On Tue, Aug 06, 2019 at 11:36:48AM +0200, Vlastimil Babka wrote:
> > On 8/6/19 3:08 AM, Suren Baghdasaryan wrote:
> > >> @@ -1280,3 +1285,50 @@ static int __init psi_proc_init(void)
> > >> return 0;
> > >> }
> > >>
On Tue, Aug 06, 2019 at 11:36:48AM +0200, Vlastimil Babka wrote:
> On 8/6/19 3:08 AM, Suren Baghdasaryan wrote:
> >> @@ -1280,3 +1285,50 @@ static int __init psi_proc_init(void)
> >> return 0;
> >> }
> >> module_init(psi_proc_init);
> >> +
> >> +#define OOM_PRESSURE_LEVEL 80
> >>
On 8/6/19 3:08 AM, Suren Baghdasaryan wrote:
>> @@ -1280,3 +1285,50 @@ static int __init psi_proc_init(void)
>> return 0;
>> }
>> module_init(psi_proc_init);
>> +
>> +#define OOM_PRESSURE_LEVEL 80
>> +#define OOM_PRESSURE_PERIOD(10 * NSEC_PER_SEC)
>
> 80% of the last 10 seconds
On Mon 05-08-19 14:55:42, Johannes Weiner wrote:
> On Mon, Aug 05, 2019 at 03:31:19PM +0200, Michal Hocko wrote:
> > On Mon 05-08-19 14:13:16, Vlastimil Babka wrote:
> > > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > > > Hello,
> > > >
> > > > There's this bug which has been bugging many
> On Mon, Aug 5, 2019 at 12:31 PM Johannes Weiner wrote:
>>
>> On Mon, Aug 05, 2019 at 02:13:16PM +0200, Vlastimil Babka wrote:
>> > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
>> > > Hello,
>> > >
>> > > There's this bug which has been bugging many people for many years
>> > > already and
On Mon, Aug 5, 2019 at 12:31 PM Johannes Weiner wrote:
>
> On Mon, Aug 05, 2019 at 02:13:16PM +0200, Vlastimil Babka wrote:
> > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > > Hello,
> > >
> > > There's this bug which has been bugging many people for many years
> > > already and which is
On Mon, Aug 05, 2019 at 02:13:16PM +0200, Vlastimil Babka wrote:
> On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > Hello,
> >
> > There's this bug which has been bugging many people for many years
> > already and which is reproducible in less than a few minutes under the
> > latest and greatest
On Mon, Aug 05, 2019 at 03:31:19PM +0200, Michal Hocko wrote:
> On Mon 05-08-19 14:13:16, Vlastimil Babka wrote:
> > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > > Hello,
> > >
> > > There's this bug which has been bugging many people for many years
> > > already and which is reproducible in
On Mon, Aug 5, 2019 at 6:31 AM Michal Hocko wrote:
>
> On Mon 05-08-19 14:13:16, Vlastimil Babka wrote:
> > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > > Hello,
> > >
> > > There's this bug which has been bugging many people for many years
> > > already and which is reproducible in less
On Mon 05-08-19 14:13:16, Vlastimil Babka wrote:
> On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> > Hello,
> >
> > There's this bug which has been bugging many people for many years
> > already and which is reproducible in less than a few minutes under the
> > latest and greatest kernel, 5.2.6.
On 8/4/19 11:23 AM, Artem S. Tashkinov wrote:
> Hello,
>
> There's this bug which has been bugging many people for many years
> already and which is reproducible in less than a few minutes under the
> latest and greatest kernel, 5.2.6. All the kernel parameters are set to
> defaults.
>
> Steps
On 8/5/19 9:05 AM, Hillf Danton wrote:
On Sun, 4 Aug 2019 09:23:17 + "Artem S. Tashkinov" wrote:
Hello,
There's this bug which has been bugging many people for many years
already and which is reproducible in less than a few minutes under the
latest and greatest kernel, 5.2.6. All the
Hello,
There's this bug which has been bugging many people for many years
already and which is reproducible in less than a few minutes under the
latest and greatest kernel, 5.2.6. All the kernel parameters are set to
defaults.
Steps to reproduce:
1) Boot with mem=4G
2) Disable swap to make
On 05/15, Sultan Alsawaf wrote:
>
> On Wed, May 15, 2019 at 04:58:32PM +0200, Oleg Nesterov wrote:
> > Could you explain in detail what exactly did you do and what do you see in
> > dmesg?
> >
> > Just in case, lockdep complains only once, print_circular_bug() does
> > debug_locks_off()
> > so
On Wed, 15 May 2019 11:52:57 -0700
Sultan Alsawaf wrote:
> On Wed, May 15, 2019 at 02:32:48PM -0400, Steven Rostedt wrote:
> > I'm confused why you did this?
>
> Oleg said that debug_locks_off() could've been called and thus prevented
> lockdep complaints about simple_lmk from appearing. To
On Wed, May 15, 2019 at 02:32:48PM -0400, Steven Rostedt wrote:
> I'm confused why you did this?
Oleg said that debug_locks_off() could've been called and thus prevented
lockdep complaints about simple_lmk from appearing. To eliminate any possibility
of that, I disabled debug_locks_off().
Oleg
On Wed, 15 May 2019 10:27:28 -0700
Sultan Alsawaf wrote:
> On Wed, May 15, 2019 at 04:58:32PM +0200, Oleg Nesterov wrote:
> > Could you explain in detail what exactly did you do and what do you see in
> > dmesg?
> >
> > Just in case, lockdep complains only once, print_circular_bug() does
> >
On 05/13, Sultan Alsawaf wrote:
>
> On Fri, May 10, 2019 at 05:10:25PM +0200, Oleg Nesterov wrote:
> > I am starting to think I am ;)
> >
> > If you have task1 != task2 this code
> >
> > task_lock(task1);
> > task_lock(task2);
> >
> > should trigger print_deadlock_bug(), task1->alloc_lock
On Tue, May 14, 2019 at 12:44:53PM -0400, Steven Rostedt wrote:
> OK, this has gotten my attention.
>
> This thread is quite long, do you have a git repo I can look at, and
> also where is the first task_lock() taken before the
> find_lock_task_mm()?
>
> -- Steve
Hi Steve,
This is the git repo
On Mon, 13 May 2019 09:45:55 -0700
Sultan Alsawaf wrote:
> On Fri, May 10, 2019 at 05:10:25PM +0200, Oleg Nesterov wrote:
> > I am starting to think I am ;)
> >
> > If you have task1 != task2 this code
> >
> > task_lock(task1);
> > task_lock(task2);
> >
> > should trigger
On Fri, May 10, 2019 at 05:10:25PM +0200, Oleg Nesterov wrote:
> I am starting to think I am ;)
>
> If you have task1 != task2 this code
>
> task_lock(task1);
> task_lock(task2);
>
> should trigger print_deadlock_bug(), task1->alloc_lock and task2->alloc_lock
> are
> the "same"
On 05/09, Sultan Alsawaf wrote:
>
> On Thu, May 09, 2019 at 05:56:46PM +0200, Oleg Nesterov wrote:
> > Impossible ;) I bet lockdep should report the deadlock as soon as
> > find_victims()
> > calls find_lock_task_mm() when you already have a locked victim.
>
> I hope you're not a betting man ;)
On Thu, May 09, 2019 at 05:56:46PM +0200, Oleg Nesterov wrote:
> Impossible ;) I bet lockdep should report the deadlock as soon as
> find_victims()
> calls find_lock_task_mm() when you already have a locked victim.
I hope you're not a betting man ;)
With the following configured:
On 05/07, Sultan Alsawaf wrote:
>
> On Tue, May 07, 2019 at 05:31:54PM +0200, Oleg Nesterov wrote:
>
> > Did you test this patch with lockdep enabled?
> >
> > If I read the patch correctly, lockdep should complain. vtsk_is_duplicate()
> > ensures that we do not take the same ->alloc_lock twice or
From: Sultan Alsawaf
Date: Tue, May 7, 2019 at 9:53 AM
To: Suren Baghdasaryan
Cc: Christian Brauner, Greg Kroah-Hartman, open list:ANDROID DRIVERS,
Daniel Colascione, Todd Kjos, Kees Cook, Peter Zijlstra, Martijn
Coenen, LKML, Tim Murray, Michal Hocko, linux-mm, Arve Hjønnevåg, Ingo
Molnar,
t; > feasible. One of the things that I have been working on for quite a
> > while is the whole file descriptor for processes thing that is important
> > for LMKD (Even though I never thought about this use-case when I started
> > pitching this.). Joel and Daniel have joined in an
On Tue, May 07, 2019 at 10:17:11AM -0700, Sultan Alsawaf wrote:
> On Tue, May 07, 2019 at 01:09:21PM +0200, Greg Kroah-Hartman wrote:
> > > It's even more odd that although a userspace solution is touted as the
> > > proper
> > > way to go on LKML, almost no Android OEMs are using it, and even in
r LMKD (Even though I never thought about this use-case when I started
> pitching this.). Joel and Daniel have joined in and are working on
> making LMKD possible.
> What I find odd is that every couple of weeks different solutions to the
> low memory problem are pitched. There is si
On Tue, May 07, 2019 at 09:28:47AM -0700, Suren Baghdasaryan wrote:
> Hi Sultan,
> Looks like you are posting this patch for devices that do not use
> userspace LMKD solution due to them using older kernels or due to
> their vendors sticking to in-kernel solution. If so, I see couple
> logistical
e solution and it is a
> process to address all concerns but we are getting there.
>
> > > Regardless, even if PSI were backported, a full-fledged LMKD using it has
> > > yet to
> > > be made, so it wouldn't be of much use now.
> >
> > This i
On Tue, May 07, 2019 at 05:31:54PM +0200, Oleg Nesterov wrote:
> I am not going to comment the intent, but to be honest I am skeptical too.
The general sentiment has been that this is a really bad idea, but I'm just a
frustrated Android user who wants his phone to not require mountains of zRAM
; > yet to
> > be made, so it wouldn't be of much use now.
>
> This is work that is ongoing and requires kernel changes to make it
> feasible. One of the things that I have been working on for quite a
> while is the whole file descriptor for processes thing that is importa
I am not going to comment the intent, but to be honest I am skeptical too.
On 05/06, Sultan Alsawaf wrote:
>
> +static unsigned long find_victims(struct victim_info *varr, int *vindex,
> + int vmaxlen, int min_adj, int max_adj)
> +{
> + unsigned long pages_found
On Mon 06-05-19 19:16:22, Sultan Alsawaf wrote:
> This is a complete low memory killer solution for Android that is small
> and simple. Processes are killed according to the priorities that
> Android gives them, so that the least important processes are always
> killed first. Processe
On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote:
> On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote:
> > Given that any "new" android device that gets shipped "soon" should be
> > using 4.9.y or newer, is this a real issue?
>
> It's certainly a real issue for
ver thought about this use-case when I started
pitching this.). Joel and Daniel have joined in and are working on
making LMKD possible.
What I find odd is that every couple of weeks different solutions to the
low memory problem are pitched. There is simple_lkml, there is LMKD, and
there was a patc
On Tue, May 07, 2019 at 09:43:34AM +0200, Greg Kroah-Hartman wrote:
> Given that any "new" android device that gets shipped "soon" should be
> using 4.9.y or newer, is this a real issue?
It's certainly a real issue for those who can't buy brand new Android devices
without software bugs every six
1 - 100 of 637 matches
Mail list logo
