Hi Atish,
On Sun, Apr 18, 2021 at 5:37 AM Atish Patra wrote:
>
> On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool wrote:
> >
> > On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti wrote:
> > >
> > > Hi Atish,
> > >
> > > Le 3/3/21 à 3:02 PM, Atish
On Mon, Apr 12, 2021 at 7:12 AM Alex Ghiti wrote:
>
> Le 4/9/21 à 10:42 AM, Vitaly Wool a écrit :
> > On Fri, Apr 9, 2021 at 3:59 PM Mike Rapoport wrote:
> >>
> >> On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote:
> >>>>
On Fri, Apr 9, 2021 at 3:59 PM Mike Rapoport wrote:
>
> On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote:
> > > > > Also, will that memory properly be exposed in the resource tree as
> > > > > System RAM (e.g., /proc/iomem) ? Otherwise some things (/proc/kcore)
> > > > > won't
Hi Alex,
> > All in all, I am quite sure now that your take on XIP is working fine.
> > The issue with single-core boot under QEmu seems to be less
> > reproducible on slower machines running QEmu and more reproducible on
> > higher performance ones. It's not clear to me if that is a QEmu
> >
On Tue, Apr 6, 2021 at 8:47 AM Alex Ghiti wrote:
>
> Hi Vitaly,
>
> Le 4/5/21 à 4:34 AM, Vitaly Wool a écrit :
> > On Sun, Apr 4, 2021 at 10:39 AM Vitaly Wool
> > wrote:
> >>
> >> On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote:
> >>>
On Sun, Apr 4, 2021 at 10:39 AM Vitaly Wool wrote:
>
> On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote:
> >
> > Hi Vitaly,
> >
> > Le 4/1/21 à 7:10 AM, Alex Ghiti a écrit :
> > > Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit :
> > >> Hi Alex,
>
On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote:
>
> Hi Vitaly,
>
> Le 4/1/21 à 7:10 AM, Alex Ghiti a écrit :
> > Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit :
> >> Hi Alex,
> >>
> >> On Thu, Apr 1, 2021 at 10:11 AM Alex Ghiti wrote:
> >>&g
Hi Alex,
On Thu, Apr 1, 2021 at 10:11 AM Alex Ghiti wrote:
>
> Hi,
>
> Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit :
> > Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit :
> >> On Tue, 30 Mar 2021 11:39:10 PDT (-0700), a...@ghiti.fr wrote:
> >>>
> >>&
it_text_begin'
> riscv64-linux-ld: init.c:(.text+0x2a0): undefined reference to
> `__init_data_begin'
all the RO sections should fit in 8 MB for xipImage. Could you please
remove the unnecessary parts from your kernel and retry?
Thanks,
Vitaly
> On 2021/3/22 8:12, Vitaly Wool wrote:
&g
space on the non-volatile storage. The physical flash address used
> > to link the kernel object files and for storing it has to be known
> > at compile time and is represented by a Kconfig option.
> >
> > XIP on RISC-V will for the time being only work on MMU-enabled
>
On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti wrote:
>
> Hi Atish,
>
> Le 3/3/21 à 3:02 PM, Atish Patra a écrit :
> > Add initial DTS for Microchip ICICLE board having only
> > essential devices (clocks, sdhci, ethernet, serial, etc).
> > The device tree is based on the U-Boot patch.
> >
> >
32-bit RISC-V uses folded page tables by default, so we should
follow that in the XIP-specific part of init too.
Signed-off-by: Vitaly Wool
Reported-by: kernel test robot
---
arch/riscv/mm/init.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/mm
On Mon, Mar 22, 2021 at 7:55 AM Alex Ghiti wrote:
>
> Le 3/21/21 à 2:06 PM, Vitaly Wool a écrit :
> > Hey Alex,
> >
> > On Sun, Mar 21, 2021 at 4:11 PM Alex Ghiti wrote:
> >>
> >> Hi Vitaly,
> >>
> >> Le 3/10/21 à 4:22 AM, Vitaly W
will for the time being only work on MMU-enabled
kernels.
Signed-off-by: Vitaly Wool
---
Changes in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
o both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant
Hey Alex,
On Sun, Mar 21, 2021 at 4:11 PM Alex Ghiti wrote:
>
> Hi Vitaly,
>
> Le 3/10/21 à 4:22 AM, Vitaly Wool a écrit :
> > Introduce XIP (eXecute In Place) support for RISC-V platforms.
> > It allows code to be executed directly from non-volatile storage
> > d
art
> ---[ end trace 126d646fc3dc0ad8 ]---
>
> To fix the issue, re-add the earlier test and set in the case where we
> have a headless page.
>
> Fixes: dcf5aedb24f8 ("z3fold: stricter locking and more careful reclaim")
> Cc: sta...@vger.kernel.org
>
will currently only work on MMU-enabled kernels.
Signed-off-by: Vitaly Wool
---
Changes in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
o both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant alignment
will currently only work on MMU-enabled kernels.
Signed-off-by: Vitaly Wool
---
Changed in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
= both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant
Hi Thomas,
On Tue, Feb 16, 2021 at 9:44 AM Thomas Hebb wrote:
>
> commit ca0246bb97c2 ("z3fold: fix possible reclaim races") introduced
> the PAGE_CLAIMED flag "to avoid racing on a z3fold 'headless' page
> release." By atomically testing and setting the bit in each of
> z3fold_free() and
On Sat, Jan 16, 2021 at 12:57 AM Vitaly Wool wrote:
>
> Sometimes, especially in a production system we may not want to
> use a "smart bootloader" like u-boot to load kernel, ramdisk and
> device tree from a filesystem on eMMC, but rather load the kernel
> from a NA
ing in MMU-enabled and MMU-disabled versions of setup_vm().
Signed-off-by: Vitaly Wool
---
Changes from v2:
* folded "RISC-V: simplify BUILTIN_DTB processing" patch
[http://lists.infradead.org/pipermail/linux-riscv/2021-January/004153.html]
Changes from v1:
* no direct initial_boot_param
On Fri, Jan 15, 2021 at 11:43 AM Anup Patel wrote:
>
> On Fri, Jan 15, 2021 at 3:18 PM Vitaly Wool wrote:
> >
> >
> >
> > On Fri, 15 Jan 2021, 10:39 Anup Patel, wrote:
> >>
> >> On Tue, Jan 12, 2021 at 2:51 AM Vitaly Wool
> >>
On Thu, Jan 14, 2021 at 5:56 PM Sebastian Andrzej Siewior
wrote:
>
> On 2021-01-14 17:29:37 [+0100], Vitaly Wool wrote:
> > On Thu, 14 Jan 2021, 17:18 Sebastian Andrzej Siewior,
> > wrote:
> > >
> > > On 2020-12-23 19:25:02 [+0100], Vitaly Wool wrote:
On Thu, 14 Jan 2021, 17:18 Sebastian Andrzej Siewior,
wrote:
>
> On 2020-12-23 19:25:02 [+0100], Vitaly Wool wrote:
> > > write the following patch according to your idea, what do you think ?
> >
> > Yep, that is basically what I was thinking of. Some nitpicks below
Provide __dtb_start as a parameter to setup_vm() in case
CONFIG_BUILTIN_DTB is true, so we don't have to duplicate
BUILTIN_DTB specific processing in MMU-enabled and MMU-disabled
versions of setup_vm().
Signed-off-by: Vitaly Wool
---
arch/riscv/kernel/head.S | 4
arch/riscv/mm/init.c
nt to have device tree compiled into the
kernel binary. Since this case is not limited to MMU-less systems,
let's support it for these which have MMU enabled too.
Signed-off-by: Vitaly Wool
---
Changelog from v1:
* no direct initial_boot_params assignment
* skips the temporary mapping for DT if BUI
On Tue, Dec 29, 2020 at 6:05 AM Anup Patel wrote:
>
> On Mon, Dec 28, 2020 at 10:08 PM Vitaly Wool wrote:
> >
> > On Mon, Dec 28, 2020 at 3:10 PM Anup Patel wrote:
> > >
> > > On Mon, Dec 28, 2020 at 7:05 PM Vitaly Wool
> > > wrote:
> > >
On Mon, Dec 28, 2020 at 3:10 PM Anup Patel wrote:
>
> On Mon, Dec 28, 2020 at 7:05 PM Vitaly Wool wrote:
> >
> > On Mon, Dec 28, 2020 at 12:59 PM Anup Patel wrote:
> > >
> > > On Sat, Dec 26, 2020 at 10:03 PM Vitaly Wool
> > > wrote:
> >
On Mon, Dec 28, 2020 at 12:59 PM Anup Patel wrote:
>
> On Sat, Dec 26, 2020 at 10:03 PM Vitaly Wool wrote:
> >
> > Sometimes, especially in a production system we may not want to
> > use a "smart bootloader" like u-boot to load kernel, ramdisk and
> &g
nt to have device tree compiled into the
kernel binary. Since this case is not limited to MMU-less systems,
let's support it for these which have MMU enabled too.
Signed-off-by: Vitaly Wool
---
arch/riscv/Kconfig | 1 -
arch/riscv/mm/init.c | 12 ++--
2 files changed, 10 insertions(+), 3
On Wed, Dec 23, 2020 at 1:44 PM tiantao (H) wrote:
>
>
> 在 2020/12/23 8:11, Vitaly Wool 写道:
> > On Tue, 22 Dec 2020, 22:06 Song Bao Hua (Barry Song),
> > wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Vitaly Wool [ma
On Tue, 22 Dec 2020, 22:06 Song Bao Hua (Barry Song),
wrote:
>
>
>
> > -Original Message-
> > From: Vitaly Wool [mailto:vitaly.w...@konsulko.com]
> > Sent: Tuesday, December 22, 2020 10:44 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: Shakeel Butt
Hi Anup,
On Tue, Dec 22, 2020 at 6:16 AM Anup Patel wrote:
>
> On Tue, Dec 22, 2020 at 2:08 AM Vitaly Wool wrote:
> >
> > Introduce XIP (eXecute In Place) support for RISC-V platforms.
> > It allows code to be executed directly from non-volatile storage
> > d
On Tue, 22 Dec 2020, 03:11 Song Bao Hua (Barry Song),
wrote:
>
>
>
> > -Original Message-
> > From: Song Bao Hua (Barry Song)
> > Sent: Tuesday, December 22, 2020 3:03 PM
> > To: 'Vitaly Wool'
> > Cc: Shakeel Butt ; Minchan Kim ;
> > Mike
&g
On Tue, Dec 22, 2020 at 2:44 AM Bin Meng wrote:
>
> Hi Vitaly,
>
> On Tue, Dec 22, 2020 at 4:39 AM Vitaly Wool wrote:
> >
> > Introduce XIP (eXecute In Place) support for RISC-V platforms.
> > It allows code to be executed directly from non-volatile storage
>
On Tue, Dec 22, 2020 at 12:37 AM Song Bao Hua (Barry Song)
wrote:
>
>
>
> > -Original Message-
> > From: Song Bao Hua (Barry Song)
> > Sent: Tuesday, December 22, 2020 11:38 AM
> > To: 'Vitaly Wool'
> > Cc: Shakeel Butt ; Minchan Kim ;
&
On Mon, Dec 21, 2020 at 10:30 PM Song Bao Hua (Barry Song)
wrote:
>
>
>
> > -Original Message-
> > From: Shakeel Butt [mailto:shake...@google.com]
> > Sent: Tuesday, December 22, 2020 10:03 AM
> > To: Song Bao Hua (Barry Song)
> > Cc: Vitaly Wool
is set.
Signed-off-by: Vitaly Wool
---
arch/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 56b6ccc0e32d..88632c9588ae 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -81,6 +81,7 @@ config JUMP_LABEL
bool "Optimize very unlikely/likely bra
-xip.lds.S
- changed long -> uintptr_t typecast in __XIP_FIXUP macro.
Changed in v3:
- rebased against latest for-next
- XIP address fixup macro now takes an argument
- SMP related fixes
Signed-off-by: Vitaly Wool
---
arch/riscv/Kconfig | 46 -
arch/riscv/Makef
On Mon, Dec 21, 2020 at 6:24 PM Minchan Kim wrote:
>
> On Sun, Dec 20, 2020 at 02:22:28AM +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about sche
On Sun, Dec 20, 2020 at 2:18 AM Matthew Wilcox wrote:
>
> On Sun, Dec 20, 2020 at 02:22:28AM +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about sche
-by: Vitaly Wool
---
mm/zsmalloc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 7289f502ffac..ff26546a7fed 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -876,22 +876,25 @@ static unsigned long obj_to_head(struct page *page
On Sat, 19 Dec 2020, 11:27 Mike Galbraith, wrote:
>
> On Sat, 2020-12-19 at 11:20 +0100, Vitaly Wool wrote:
> > Hi Mike,
> >
> > On Sat, Dec 19, 2020 at 11:12 AM Mike Galbraith wrote:
> > >
> > > (mailer partially munged formatting? resend)
> >
Hi Mike,
On Sat, Dec 19, 2020 at 11:12 AM Mike Galbraith wrote:
>
> (mailer partially munged formatting? resend)
>
> mm/zswap: fix zswap_frontswap_load() vs zsmalloc::map/unmap() might_sleep()
> splat
>
> zsmalloc map/unmap methods use preemption disabling bit spinlocks. Take the
> mutex
Hi Mike,
On 2020-12-07 16:41, Mike Galbraith wrote:
On Mon, 2020-12-07 at 16:21 +0100, Vitaly Wool wrote:
On Mon, Dec 7, 2020 at 1:34 PM Mike Galbraith wrote:
Unfortunately, that made zero difference.
Okay, I suggest that you submit the patch that changes read_lock() to
write_lock
On Mon, Dec 7, 2020 at 1:34 PM Mike Galbraith wrote:
>
> On Mon, 2020-12-07 at 12:52 +0100, Vitaly Wool wrote:
> >
> > Thanks. This trace beats me because I don't quite get how this could
> > have happened.
>
> I swear there's a mythical creature loose in there so
On Mon, Dec 7, 2020 at 3:18 AM Mike Galbraith wrote:
>
> On Mon, 2020-12-07 at 02:05 +0100, Vitaly Wool wrote:
> >
> > Could you please try the following patch in your setup:
>
> crash> gdb list *z3fold_zpool_free+0x527
> 0xc0e14487 is in z3fold_zpool
On Thu, Dec 3, 2020 at 2:39 PM Sebastian Andrzej Siewior
wrote:
>
> On 2020-12-03 09:18:21 [+0100], Mike Galbraith wrote:
> > On Thu, 2020-12-03 at 03:16 +0100, Mike Galbraith wrote:
> > > On Wed, 2020-12-02 at 23:08 +0100, Sebastian Andrzej Siewior wrote:
> > > Looks like...
> > >
> > >
-xip.lds.S
- changed long -> uintptr_t typecast in __XIP_FIXUP macro.
Signed-off-by: Vitaly Wool
---
arch/riscv/Kconfig | 40 -
arch/riscv/Makefile | 8 +-
arch/riscv/boot/Makefile| 14 ++-
arch/riscv/include/asm/pgtable.h|
On Wed, Dec 2, 2020 at 7:06 PM Nicolas Pitre wrote:
>
> On Wed, 2 Dec 2020, Vitaly Wool wrote:
>
> > Introduce XIP (eXecute In Place) support for RISC-V platforms.
> > It allows code to be executed directly from non-volatile storage
> > directly addressable by the
will currently only work on MMU-enabled kernels.
Signed-off-by: Vitaly Wool
---
arch/riscv/Kconfig | 40 +++-
arch/riscv/Makefile | 8 +-
arch/riscv/boot/Makefile| 14 ++-
arch/riscv/include/asm/pgtable.h| 53 +--
arch/riscv/kernel
On Tue, Dec 1, 2020 at 6:40 PM Atish Patra wrote:
>
> On Tue, Dec 1, 2020 at 1:01 AM wrote:
> >
> > From: Vitaly Wool
> >
> > Cuurently mmu_enabled flag is set to true way later than the actual
> > MMU enablement takes place. This leads to hard-to-t
From: Vitaly Wool
Cuurently mmu_enabled flag is set to true way later than the actual
MMU enablement takes place. This leads to hard-to-track races in
e. g. SBI earlycon initialization taking wrong path configuring
fixmap.
To fix that, move mmu_enabled toggling to head.S and rename
ior
> Cc: Andrew Morton
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Mahipal Challa
> Cc: Seth Jennings
> Cc: Dan Streetman
> Cc: Vitaly Wool
> Cc: Zhou Wang
> Cc: Hao Fang
> Cc: Colin Ian King
> Signed-off-by: Barry Song
Acked-by: Vitaly Wool
> ---
M
> >> To: Colin King
> >> Cc: Seth Jennings ; Dan Streetman
> >> ; Vitaly Wool ; Andrew
> >> Morton ; Song Bao Hua (Barry Song)
> >> ; Stephen Rothwell ;
> >> linux...@kvack.org; kernel-janit...@vger.kernel.org;
> >> linux-kernel@vg
> Cc: Sebastian Andrzej Siewior
> Cc: Andrew Morton
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Mahipal Challa
> Cc: Seth Jennings
> Cc: Dan Streetman
> Cc: Vitaly Wool
> Cc: Zhou Wang
> Signed-off-by: Barry Song
> ---
> -v2:
> rebase to 5.8-rc1
On Tue, May 19, 2020 at 5:50 AM Qian Cai wrote:
>
> >
> > Removing that check in ->isolate() is not a big deal, but ->migratepage()
> > shall not allow actual migration anyway if there are mapped objects.
>
> Is that worse than an endless loop here?
Well, let's figure if there really has to be
On Tue, Oct 15, 2019 at 10:00 PM Minchan Kim wrote:
>
> On Tue, Oct 15, 2019 at 09:39:35AM +0200, Vitaly Wool wrote:
> > Hi Minchan,
> >
> > On Mon, Oct 14, 2019 at 6:41 PM Minchan Kim wrote:
> > >
> > > On Thu, Oct 10, 2019 at 11:04:14PM +0300, Vita
Hi Minchan,
On Mon, Oct 14, 2019 at 6:41 PM Minchan Kim wrote:
>
> On Thu, Oct 10, 2019 at 11:04:14PM +0300, Vitaly Wool wrote:
> > The coming patchset is a new take on the old issue: ZRAM can currently be
> > used only with zsmalloc even though this may not be the o
On Mon, Oct 14, 2019 at 12:49 PM Sergey Senozhatsky
wrote:
>
> On (10/10/19 23:20), Vitaly Wool wrote:
> [..]
> > static const char *default_compressor = "lzo-rle";
> >
> > +#define BACKEND_PAR_BUF_SIZE 32
> > +static char backend_par_buf[BACKEND_P
Hi Sergey,
On Mon, Oct 14, 2019 at 12:35 PM Sergey Senozhatsky
wrote:
>
> Hi,
>
> On (10/10/19 23:04), Vitaly Wool wrote:
> [..]
> > The coming patchset is a new take on the old issue: ZRAM can
> > currently be used only with zsmalloc even though this may not
>
-by: Vitaly Wool
---
drivers/block/zram/Kconfig| 3 ++-
drivers/block/zram/zram_drv.c | 64 +++
drivers/block/zram/zram_drv.h | 4 +--
3 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index
Add compaction callbacks for zpool compaction API extension.
Add huge_class_size callback too to be fully aligned.
With these in place, we can proceed with ZRAM modification
to use the universal (zpool) API.
Signed-off-by: Vitaly Wool
---
mm/zsmalloc.c | 21 +
1 file
existence and the third one returns
the huge class size.
This API extension is done to align zpool API with zsmalloc API.
Signed-off-by: Vitaly Wool
---
include/linux/zpool.h | 14 +-
mm/zpool.c| 36
2 files changed, 49 insertions(+), 1
The coming patchset is a new take on the old issue: ZRAM can currently be used
only with zsmalloc even though this may not be the optimal combination for some
configurations. The previous (unsuccessful) attempt dates back to 2015 [1] and
is notable for the heated discussions it has caused.
The
From: Vitaly Wool
For each page scheduled for compaction (e. g. by z3fold_free()),
try to apply inter-page compaction before running the traditional/
existing intra-page compaction. That means, if the page has only one
buddy, we treat that buddy as a new object that we aim to place
faults (since
that page would have been reclaimed by then). Fix that by
claiming page in the beginning of z3fold_free() and not
forgetting to clear the claim in the end.
Reported-by: Markus Linnala
Signed-off-by: Vitaly Wool
Cc:
---
mm/z3fold.c | 10 --
1 file changed, 8 insertions(+), 2
faults (since
that page would have been reclaimed by then). Fix that by
claiming page in the beginning of z3fold_free().
Reported-by: Markus Linnala
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index
On Wed, Sep 18, 2019 at 9:35 AM Vlastimil Babka wrote:
>
> On 9/17/19 5:53 PM, Vitaly Wool wrote:
> > Currently there is a leak in init_z3fold_page() -- it allocates
> > handles from kmem cache even for headless pages, but then they are
> > never used and never freed, so e
Currently there is a leak in init_z3fold_page() -- it allocates
handles from kmem cache even for headless pages, but then they are
never used and never freed, so eventually kmem cache may get
exhausted. This patch provides a fix for that.
Reported-by: Markus Linnala
Signed-off-by: Vitaly Wool
a handle _that_ fast as
zswap_writeback_entry() does when it reads swpentry, the
suggestion is to keep the handle mapped till the end.
Signed-off-by: Vitaly Wool
---
mm/zswap.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 0e22744a76cb
.
Reported-by: Agustín Dall'Alba
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 90 -
1 file changed, 90 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 75b7962439ff..ed19d98c9dcd 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -41,7
On Sun, Sep 8, 2019 at 4:56 PM Maciej S. Szmigiero
wrote:
>
> On 08.09.2019 15:29, Vitaly Wool wrote:
> > z3fold_page_reclaim()'s retry mechanism is broken: on a second
> > iteration it will have zhdr from the first one so that zhdr
> > is no longer in line with struct pag
freed handles by using
own local slots structure in z3fold_page_reclaim().
Reported-by: Markus Linnala
Reported-by: Chris Murphy
Reported-by: Agustin Dall'Alba
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 49 ++---
1 file changed, 34 insertions(+), 15
Hi Henry,
Den fre 9 aug. 2019 6:46 emHenry Burns skrev:
>
> In z3fold_destroy_pool() we call destroy_workqueue(>compact_wq).
> However, we have no guarantee that migration isn't happening in the
> background at that time.
>
> Migration directly calls queue_work_on(pool->compact_wq), if
y related flags from the call to kmem_cache_alloc()
> for our slots since it is a kernel allocation.
>
> Signed-off-by: Henry Burns
Acked-by: Vitaly Wool
> ---
> mm/z3fold.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/z3fo
>From fd87fdc38ea195e5a694102a57bd4d59fc177433 Mon Sep 17 00:00:00 2001
From: Vitaly Wool
Date: Mon, 8 Jul 2019 13:41:02 +0200
[PATCH] mm/z3fold: don't try to use buddy slots after free
As reported by Henry Burns:
Running z3fold stress testing with address sanitization
showed zhdr->
On Tue, Jul 2, 2019 at 6:57 PM Henry Burns wrote:
>
> On Tue, Jul 2, 2019 at 12:45 AM Vitaly Wool wrote:
> >
> > Hi Henry,
> >
> > On Mon, Jul 1, 2019 at 8:31 PM Henry Burns wrote:
> > >
> > > Running z3fold stress testing with address sanitizati
On Wed, Jul 3, 2019 at 12:18 AM Henry Burns wrote:
>
> On Tue, Jul 2, 2019 at 2:19 PM Andrew Morton
> wrote:
> >
> > On Mon, 1 Jul 2019 18:16:30 -0700 Henry Burns wrote:
> >
> > > Cc: Vitaly Wool , Vitaly Vul
> >
> > Are these the same person?
&
On Wed, Jul 3, 2019 at 12:24 AM Andrew Morton wrote:
>
> On Tue, 2 Jul 2019 15:17:47 -0700 Henry Burns wrote:
>
> > > > > > + if (can_sleep) {
> > > > > > + lock_page(page);
> > > > > > + __SetPageMovable(page, pool->inode->i_mapping);
> > > > > > +
assed in locked, as documentation.
>
> Signed-off-by: Henry Burns
> Suggested-by: Vitaly Wool
Acked-by: Vitaly Wool
Thanks!
> ---
> Changelog since v1:
> - Added an if statement around WARN_ON(trylock_page(page)) to avoid
>unlocking a page locked by a someone else.
&
Hi Henry,
On Mon, Jul 1, 2019 at 8:31 PM Henry Burns wrote:
>
> Running z3fold stress testing with address sanitization
> showed zhdr->slots was being used after it was freed.
>
> z3fold_free(z3fold_pool, handle)
> free_handle(handle)
> kmem_cache_free(pool->c_handle, zhdr->slots)
>
Hi Shakeel,
On Wed, Jun 5, 2019 at 6:31 PM Shakeel Butt wrote:
>
> On Wed, Jun 5, 2019 at 3:06 AM Hui Zhu wrote:
> >
> > As a zpool_driver, zsmalloc can allocate movable memory because it
> > support migate pages.
> > But zbud and z3fold cannot allocate movable memory.
> >
>
> Cc: Vitaly
significantly better average compression ratio.
Changes from v1:
* balanced use of inlining
* more comments in the key parts of code
* code rearranged to avoid forward declarations
* rwlock instead of seqlock
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 538 +
On Sun, May 26, 2019 at 12:09 AM Andrew Morton
wrote:
> Forward-declaring inline functions is peculiar, but it does appear to work.
>
> z3fold is quite inline-happy. Fortunately the compiler will ignore the
> inline hint if it seems a bad idea. Even then, the below shrinks
> z3fold.o text
significantly better average compression ratio.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 328 +---
1 file changed, 285 insertions(+), 43 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 985732c8b025..d82bccc8bc90 100644
--- a/mm/z
kmem_cache_alloc() may be called from z3fold_alloc() in atomic
context, so we need to pass correct gfp flags to avoid "scheduling
while atomic" bug.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/mm/z3f
the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 241 +---
1 file changed, 231 insertions(+), 10 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index
.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 36
1 file changed, 36 insertions(+)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 7a59875d880c..29a4f1249bef 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -522,6 +522,42 @@ static inline struct z3fold_header
page is moved.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 185
1 file changed, 145 insertions(+), 40 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 29a4f1249bef..bebc10083f1c 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -34,6 +34,29
This patch introduces a separate helper function for object
allocation, as well as 2 smaller helpers to add a buddy to the list
and to get a pointer to the pool from the z3fold header. No
functional changes here.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 184
consumption) is
included in this patchset.
Vitaly Wool (4):
z3fold: introduce helper functions
z3fold: improve compression by extending search
z3fold: add structure for buddy handles
z3fold: support page migration
mm/z3fold.c | 638
Den ons 17 apr. 2019 kl 01:18 skrev Andrew Morton :
>
> On Thu, 11 Apr 2019 17:32:12 +0200 Vitaly Wool wrote:
>
> > This patchset implements page migration support and slightly better
> > buddy search. To implement page migration support, z3fold has to move
> > a
the page if
z3fold_page_migrate() for it failed permanently (i. e. not with
-EAGAIN code).
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 241 +---
1 file changed, 231 insertions(+), 10 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index
page is moved.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 185
1 file changed, 145 insertions(+), 40 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 29a4f1249bef..bebc10083f1c 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -34,6
for that object.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 36
1 file changed, 36 insertions(+)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 7a59875d880c..29a4f1249bef 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -522,6 +522,42 @@ static inline struct z3fold_header
This patch introduces a separate helper function for object
allocation, as well as 2 smaller helpers to add a buddy to the list
and to get a pointer to the pool from the z3fold header. No
functional changes here.
Signed-off-by: Vitaly Wool
---
mm/z3fold.c | 184
memory consumption) is
included in this patchset.
Vitaly Wool (4):
z3fold: introduce helper functions
z3fold: improve compression by extending search
z3fold: add structure for buddy handles
z3fold: support page migration
mm/z3fold.c | 638
ch) the right way?
I could apply the new patch on top of yours but that would effectively
revert most of your changes.
Would it be ok for you if I add you to Signed-off-by for the new patch instead?
~Vitaly
> I'm sorry I sent reply twice.
>
> Best regards,
> Jongseok
>
>
> &
ch) the right way?
I could apply the new patch on top of yours but that would effectively
revert most of your changes.
Would it be ok for you if I add you to Signed-off-by for the new patch instead?
~Vitaly
> I'm sorry I sent reply twice.
>
> Best regards,
> Jongseok
>
>
> &
1 - 100 of 460 matches
Mail list logo
