tl_compaction_order scaled by the zone's size. It
> * returns a value in the range [0, 100].
> *
> * The scaling factor ensures that proactive compaction focuses on larger
> @@ -2666,6 +2666,7 @@ static void compact_nodes(void)
> * background. It takes values in the range [0
Hello.
On Tue, Apr 06, 2021 at 11:48:02AM -0700, Jakub Kicinski wrote:
> On Tue, 6 Apr 2021 14:36:19 +0200 Oleksandr Natalenko wrote:
> > Hello.
> >
> > I've raised this here [1] first, but was suggested to engage igb devs,
> > so here we are.
> >
> > I'
a.kernel.org/show_bug.cgi?id=211911
--
Oleksandr Natalenko (post-factum)
4
[64924.105357] RSP: 002b:7ffcc0fdc988 EFLAGS: 0246 ORIG_RAX:
0001
```
I'm not quite positive about having an exact reproducer, unfortunately.
Have you got an idea on what could go wrong here?
Thanks.
--
Oleksandr Natalenko (post-factum)
Hello.
On Wed, Mar 31, 2021 at 07:21:07PM +, Nick Terrell wrote:
>
>
> > On Mar 31, 2021, at 10:48 AM, Oleksandr Natalenko
> > wrote:
> >
> > Hello.
> >
> > On Wed, Mar 31, 2021 at 05:39:25PM +, Nick Terrell wrote:
> >>
> >
Hello.
On Wed, Mar 31, 2021 at 05:39:25PM +, Nick Terrell wrote:
>
>
> > On Mar 30, 2021, at 4:50 AM, Oleksandr Natalenko
> > wrote:
> >
> > On Tue, Mar 30, 2021 at 01:32:35PM +0200, Piotr Gorski wrote:
> >> kmod 28 supports modules
ucts directly with a typedef to get a kernel style name.
> This removes the memcpy cruft.
> * (1/3) Undo ZSTD_WINDOWLOG_MAX and handle_zstd_error changes.
> * (3/3) Expose zstd_errors.h as `include/linux/zstd_errors.h` because it
> is needed by the kernel wrapper API.
>
>
2281,6 +2281,9 @@ config MODULE_COMPRESS_GZIP
> config MODULE_COMPRESS_XZ
> bool "XZ"
>
> +config MODULE_COMPRESS_ZSTD
> + bool "ZSTD"
> +
> endchoice
>
> config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
> --
> 2.31.0.97.g1424303
t
see it being used anywhere else.
--
Oleksandr Natalenko (post-factum)
] drm_ioctl+0x222/0x3c0 [drm]
[ 3676.034071] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 3676.034145] __x64_sys_ioctl+0x83/0xb0
[ 3676.034149] do_syscall_64+0x33/0x40
…
[ 3676.034171] ---[ end trace 66e9865b027112f3 ]---
```
Thanks.
--
Oleksandr Natalenko (post-factum)
| 8 +
> 4 files changed, 402 insertions(+), 22 deletions(-)
>
> --
> 2.20.1
I'm running the kernel with this submission applied on multiple machines
for 3 weeks now and haven't encountered any visible issues.
Tested-by: Oleksandr Natalenko
Thanks.
--
Oleksandr Natalenko (post-factum)
uld prefer to be called --- for example, would you prefer
> that start an e-mail with the salutation, "Hi Gao", "Hi Xiang", or "Hi
> Gao Xiang"?
Is there a common way to indicate that? Like, erm, SPDX, but for names?
Saying, instead of just writing "Oleksandr
fig"
>
> endmenu
> endif # BLOCK
> --
> 2.25.4
>
It seems fs/Makefile modification has been dropped from this patch for
some reason. Mistake?
--
Oleksandr Natalenko (post-factum)
gt; + break;
> + len -= add;
> + }
> + } while (run_get_entry(run, ++run_idx, NULL, , ));
> +
> + if (bio) {
> + if (!err)
> + err = submit_bio_wait(bio);
> + bio_put(bio);
> + }
> + blk_finish_plug();
> +out:
> + unlock_page(fill);
> + put_page(fill);
> +
> + return err;
> +}
>
> ...SNIP...
>
--
Oleksandr Natalenko (post-factum)
44 lib/zstd/decompress/zstd_decompress.c
> create mode 100644 lib/zstd/decompress/zstd_decompress_block.c
> create mode 100644 lib/zstd/decompress/zstd_decompress_block.h
> create mode 100644 lib/zstd/decompress/zstd_decompress_internal.h
> create mode 100644 lib/zstd/decompress_sources.h
> delete mode 100644 lib/zstd/entropy_common.c
> delete mode 100644 lib/zstd/error_private.h
> delete mode 100644 lib/zstd/fse.h
> delete mode 100644 lib/zstd/fse_compress.c
> delete mode 100644 lib/zstd/fse_decompress.c
> delete mode 100644 lib/zstd/huf.h
> delete mode 100644 lib/zstd/huf_compress.c
> delete mode 100644 lib/zstd/huf_decompress.c
> delete mode 100644 lib/zstd/mem.h
> delete mode 100644 lib/zstd/zstd_common.c
> create mode 100644 lib/zstd/zstd_compress_module.c
> create mode 100644 lib/zstd/zstd_decompress_module.c
> delete mode 100644 lib/zstd/zstd_internal.h
> delete mode 100644 lib/zstd/zstd_opt.h
>
> --
> 2.29.2
>
So, what's the fate of this submission please?
Thanks.
--
Oleksandr Natalenko (post-factum)
lopers will answer you.
Thanks.
[1]
https://gitlab.com/post-factum/pf-kernel/-/commit/e487427ef07c735fdc711a56d1ceac6629c34dcf.patch
[2] https://aur.archlinux.org/packages/ntfs3-dkms/
--
Oleksandr Natalenko (post-factum)
al (and/or, potentially, older stable
branches
as well)?
--
Oleksandr Natalenko (post-factum)
else if (bfq_may_expire_for_budg_timeout(bfqq))
> > + } else if (bfq_may_expire_for_budget_timeout(bfqq))
> > bfq_bfqq_expire(bfqd, bfqq, false,
> > BFQQE_BUDGET_TIMEOUT);
> > else if (RB_EMPTY_ROOT(>sort_list) &&
> > --
> > 1.8.3.1
> >
>
Was this sent to some mailing list? I don't see an original email with
this patch.
--
Oleksandr Natalenko (post-factum)
e;
> >
> > - if (!next_in_service)
> > - return parent_sched_may_change;
> > -
Unless I'm missing something, this has already been fixed here:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.12/block=1a23e06cdab2be07cbda460c6417d7de564c48e6
> > return parent_sched_may_change;
> > }
> >
> > --
> > 1.8.3.1
> >
>
--
Oleksandr Natalenko (post-factum)
On Sat, Feb 06, 2021 at 05:57:45PM +0100, Oleksandr Natalenko wrote:
> On Sat, Feb 06, 2021 at 01:43:10AM +0500, Hanabishi Recca wrote:
> > Can't even build v20 due to compilation errors.
>
> Try this please: http://ix.io/2OwR
Slightly reworked version: http://ix.io/2Oxa
On Sat, Feb 06, 2021 at 01:43:10AM +0500, Hanabishi Recca wrote:
> Can't even build v20 due to compilation errors.
Try this please: http://ix.io/2OwR
--
Oleksandr Natalenko (post-factum)
On Sat, Feb 06, 2021 at 01:43:10AM +0500, Hanabishi Recca wrote:
> Can't even build v20 due to compilation errors.
I think this submission is based against linux-next branch where
idmapped mounts are introduced, hence it is not applicable to v5.10 and
v5.11 any more.
--
Oleksandr Natale
On Mon, Jan 04, 2021 at 09:10:17PM +0100, Oleksandr Natalenko wrote:
> On Mon, Jan 04, 2021 at 08:04:08PM +0100, Andre Tomt wrote:
> > On 28.12.2020 13:50, Greg Kroah-Hartman wrote:
> > > From: Stylon Wang
> > >
> > > commit a135a1b4c4db1f3b8cbed9676a40ede3
> And I suspect this is the same:
> https://bugs.archlinux.org/task/69202
>
> Reverting it from 5.10.4 makes things behave again.
>
> Have not tested 5.4.86 or 5.11-rc.
>
> I'm using a RX570 Polaris based card.
--
Oleksandr Natalenko (post-factum)
.
Thank you.
[1]
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/545e2917dbd863760a51379de8c26631e667c563^!/
--
Oleksandr Natalenko (post-factum)
On Sat, Dec 05, 2020 at 05:19:18PM +0100, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 21:19, Oleksandr Natalenko wrote:
> > On Thu, Dec 03, 2020 at 07:04:00PM +,
> > bugzilla-dae...@bugzilla.kernel.org wrote:
> >>2) Have a wrapper around handle_gen
guru here either, just looking around the code */
[1]
https://elinux.org/images/f/f6/ELCE15-WolframSang-ShinyNewI2CSlaveFramework.pdf
```
and also tglx' follow-up question:
```
The question is whether it's guaranteed under all circumstances
including forced irq threading. The i801 driver has assumptions about
this, so I wouldn't be surprised if there are more.
```
Thanks.
--
Oleksandr Natalenko (post-factum)
On Mon, Nov 30, 2020 at 02:20:14PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-29 12:41:14 [+0100], Mike Galbraith wrote:
> > On Sun, 2020-11-29 at 12:29 +0100, Oleksandr Natalenko wrote:
> > >
> > > Ummm so do compressors explode under non-rt kernel
Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote:
> > > > >
> > > > > > > Shouldn't the list manipulation be protected with
> > > > > > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock?
> > > > >
> &g
On Sat, Nov 28, 2020 at 03:09:24PM +0100, Oleksandr Natalenko wrote:
> > While running v5.10-rc5-rt11 I bumped into the following:
> >
> > ```
> > BUG: scheduling while atomic: git/18695/0x0002
> > Preemption disabled at:
> > [] z3fold_zpool_mal
ot;Fully Preemptible Kernel (Real-Time)"
> depends on EXPERT && ARCH_SUPPORTS_RT
> select PREEMPTION
> + select RT_MUTEXES
> help
> This option turns the kernel into a real-time kernel by replacing
> various locking primitives (spinlocks, rwlocks, etc.) with
> diff --git a/localversion-rt b/localversion-rt
> index d79dde624aaac..05c35cb580779 100644
> --- a/localversion-rt
> +++ b/localversion-rt
> @@ -1 +1 @@
> --rt10
> +-rt11
--
Oleksandr Natalenko (post-factum)
On Sat, Nov 28, 2020 at 03:05:24PM +0100, Oleksandr Natalenko wrote:
> Hi.
>
> While running v5.10-rc5-rt11 I bumped into the following:
>
> ```
> BUG: scheduling while atomic: git/18695/0x0002
> Preemption disabled at:
> [] z3fold_zpool_malloc+0x463/0x6e0
> …
smp_processor_id();
652 put_cpu_ptr(pool->unbuddied);
653 }
654 }
```
Shouldn't the list manipulation be protected with
local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock?
Thanks.
--
Oleksandr Natalenko (post-factum)
Hello.
On 25.11.2020 09:32, Greg Kroah-Hartman wrote:
On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote:
Hi.
On 24.11.2020 15:23, Ard Biesheuvel wrote:
> Surely caused by
>
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ef
in the latest stable kernel.
/cc Greg
--
Oleksandr Natalenko (post-factum)
On 16.11.2020 11:31, Valentin Schneider wrote:
On 16/11/20 10:27, Oleksandr Natalenko wrote:
Hi.
[...]
Not sure whether the check is legitimate, but FWIW I've managed to put
a
test task [1] (it spawns a lot of threads and applies affinity) into a
permanent unkillable D state here:
```
[&l
On 16.11.2020 11:27, Oleksandr Natalenko wrote:
Not sure whether the check is legitimate, but FWIW I've managed to put
a test task [1] (it spawns a lot of threads and applies affinity) into
a permanent unkillable D state here:
Just to make it clear: I neither applied your patch nor saw a splat
Hi.
On 16.11.2020 11:00, Valentin Schneider wrote:
On 15/11/20 22:32, Oleksandr Natalenko wrote:
I'm running v5.10-rc3-rt7 for some time, and I came across this splat
in
dmesg:
```
[118769.951010] [ cut here ]
[118769.951013] WARNING: CPU: 19 PID: 146 at kernel/sched
goto out;
2015 }
```
I'm not sure what triggered this, and the system still looks usable
afterwards. I have no idea how to trigger it again ATM, so this is just
a heads up in case you know what could go wrong.
Thanks.
--
Oleksandr Natalenko (post-factum)
FS and btrfs, no write
hole (we
don't update existing stripes in place) and we don't have to fragment
writes
either like ZFS does. Add to that the caching that we already do and
it's
turning into a pretty amazing tool for managing a whole bunch of mixed
storage.
--
Oleksandr Natalenko (post-factum)
if (bfqq && !is_in_service)
bfq_put_queue(bfqq);
- else
- bfqg_and_blkg_put(container_of(entity, struct bfq_group,
- entity));
}
/**
No crashes reported this time, at least so far.
Thanks.
--
Oleksandr Natalenko (post-factum)
is one crashes too [1], and this happens even earlier than
with v2.
[1]
http://pix.academ.info/images/img/2020/07/27/91f656514707728730b0b67f8c9f4a04.jpg
--
Oleksandr Natalenko (post-factum)
vice tree either, then release the service reference to
As reported by one of my customers, this patch causes the following
crash: [1]
[1]
http://pix.academ.info/images/img/2020/07/26/52d097c02b6061657443bba92de75e8a.jpg
--
Oleksandr Natalenko (post-factum)
and fails to be applied cleanly.
Thanks.
--
Oleksandr Natalenko (post-factum)
| 3 +-
> include/linux/pid.h | 1 +
> include/linux/syscalls.h| 2 +
> include/uapi/asm-generic/unistd.h | 4 +-
> kernel/exit.c | 17 --
> kernel/pid.c| 17 ++
> kernel/sys_ni.c | 2 +
> mm/madvise.c| 190 +---
> 28 files changed, 217 insertions(+), 46 deletions(-)
>
> --
> 2.27.0.111.gc72c7da667-goog
>
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
ann put an a new note in the thread,
> I detach the patch from this patchset.
>
> Please send the KSM patch based on this patchset if you belive there is
> no need to be actionable for comments.
I don't think we came to some definite conclusion, but I'll try to implement
Vlastimil's suggestion and then send it separately for evaluation.
Lets keep KSM bit out of your submission so I won't slow it down.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
d like to know you closer.
Thanks.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
.c
@@ -119,9 +119,8 @@ mt76x2e_suspend(struct pci_dev *pdev, pm_message_t state)
mt76x02_dma_reset(dev);
-pci_enable_wake(pdev, pci_choose_state(pdev, state), true);
pci_save_state(pdev);
-err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
+err = pci_set_power_state(pdev, PCI_D0);
if (err)
goto restore;
?
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
struct mt76x02_dev *dev = container_of(mdev, struct mt76x02_dev,
> > > mt76);
> > > + int i, err;
>
> can you please double-check what is the PCI state requested during suspend?
Do you mean ACPI S3 (this is the state the system enters)? If not,
what should I check and wher
2 spock kernel: cfg80211_shutdown_all_interfaces+0x71/0xd0
[cfg80211]
čen 18 23:12:02 spock kernel: ieee80211_reconfig+0xa2/0x1700 [mac80211]
čen 18 23:12:02 spock kernel: ieee80211_restart_work+0xb7/0xe0 [mac80211]
čen 18 23:12:02 spock kernel: process_one_work+0x1d4/0x3c0
čen 18 23:12:02 spock
l series only.
Do you have any idea what could go wrong and how to approach the issue?
Thanks.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
between each check
> (=> ~30 seconds between retries).
>
> [1] https://patchwork.kernel.org/patch/11098289/
> [2] https://lore.kernel.org/linux-mm/20161230131412.gi13...@dhcp22.suse.cz/
> [3] https://lwn.net/Articles/817905/
>
> Signed-off-by: Nitin Gupta
&g
On Mon, Jun 15, 2020 at 10:29:01AM +0200, Oleksandr Natalenko wrote:
> Just to let you know, this fails to compile for me with THP disabled on
> v5.8-rc1:
>
> CC mm/compaction.o
> In file included from ./include/linux/dev_printk.h:14,
> from ./include
^~~
mm/compaction.c:1898:28: note: in expansion of macro ‘COMPACTION_HPAGE_ORDER’
1898 |extfrag_for_order(zone, COMPACTION_HPAGE_ORDER);
|^~
In function ‘fragmentation_score_zone’,
inlined from ‘kcompactd’ at mm
afterwards.
[1] https://lore.kernel.org/lkml/20191211104619.114557-1-oleksa...@redhat.com/
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
ault CC_OPTIMIZE_FOR_PERFORMANCE_O3 if GCC_VERSION >= 10
> + default CC_OPTIMIZE_FOR_PERFORMANCE if (GCC_VERSION < 10 ||
> CC_IS_CLANG)
>
> config CC_OPTIMIZE_FOR_PERFORMANCE
> bool "Optimize for performance (-O2)"
> --
> 2.26.2
>
~~
> > >
> > > I had to add 2 small patches to have clean madvise.c builds:
> > >
> >
> > hm, not sure why these weren't noticed sooner, thanks.
> >
> > This patchset is looking a bit tired now.
> >
> > Things to be addressed (might be out of date):
> >
> > - http://lkml.kernel.org/r/293bcd25-934f-dd57-3314-bbcf00833...@redhat.com
>
> It seems to be not related to process_madvise.
>
> >
> > - http://lkml.kernel.org/r/2a767d50-4034-da8c-c40c-280e0dda9...@suse.cz
> > (I did this)
>
> Thanks!
>
> >
> > - http://lkml.kernel.org/r/20200310222008.gb72...@google.com
>
> I will send foldable patches to handle comments.
>
> >
> > - issues arising from the review of
> > http://lkml.kernel.org/r/20200302193630.68771-8-minc...@kernel.org
>
> Oleksandr, What's the outcome of this issue?
> Do we still need to change based on the comment?
>
My current understanding is that we do not mess with signals excessively
in the given code path.
--
Best regards,
Oleksandr Natalenko (post-factum)
Principal Software Maintenance Engineer
to start AP, connect to
it and conduct a couple of simple speed tests.
I'll use it more today and will let you know in case something breaks.
--
Oleksandr Natalenko (post-factum)
Hello.
On 15.10.2019 18:52, Oleksandr Natalenko wrote:
Thanks for the answer and the IRC discussion. As agreed I've applied
[1] and [2], and have just swapped the card to try it again. So far,
it works fine in 5 GHz band in 802.11ac mode as an AP.
I'll give it more load with my phone over
/LorenzoBianconi/wireless-drivers-next/commit/cf3436c42a297967235a9c9778620c585100529e.patch
[2]
https://github.com/LorenzoBianconi/wireless-drivers-next/commit/aad256eb62620f9646d39c1aa69234f50c89eed8.patch
--
Oleksandr Natalenko (post-factum)
On 19.09.2019 23:22, Oleksandr Natalenko wrote:
It checks for TX hang here:
=== mt76x02_mmio.c
557 void mt76x02_wdt_work(struct work_struct *work)
558 {
...
562 mt76x02_check_tx_hang(dev);
===
I've commented out the watchdog here ^^, and the card is not resetted
any more, but similarly
On 19.09.2019 18:24, Oleksandr Natalenko wrote:
[ +9,979664] mt76x2e :01:00.0: Firmware Version: 0.0.00
[ +0,14] mt76x2e :01:00.0: Build: 1
[ +0,10] mt76x2e :01:00.0: Build Time: 201507311614
[ +0,018017] mt76x2e :01:00.0: Firmware running!
[ +0,001101] ieee80211
omewhat relevant thread I was able to found is [1], but it's
not clear what's the resolution if any.
Could you please suggest how to deal with this issue?
Thanks.
[1] https://forum.openwrt.org/t/wifi-issues-with-18-06-4-on-mt76/40537
--
Oleksandr Natalenko (post-factum)
Signed-off-by: Oleksandr Natalenko
---
fs/shiftfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/shiftfs.c b/fs/shiftfs.c
index 49f6714e9f95..14f3764577d8 100644
--- a/fs/shiftfs.c
+++ b/fs/shiftfs.c
@@ -1526,7 +1526,7 @@ static bool in_ioctl_whitelist(int flag
for something that is
bindfs but in-kernel) :).
Oleksandr Natalenko (1):
shiftfs-5.2: use copy_from_user() correctly
fs/shiftfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.22.1
Erm. Cc: s.parscha...@gmx.de instead of inactive @suse address.
On Fri, Jun 21, 2019 at 11:17:36AM +0200, Oleksandr Natalenko wrote:
> I've spotted another Chicony PixArt mouse in the wild, which requires
> HID_QUIRK_ALWAYS_POLL quirk, otherwise it disconnects each minute.
>
/sriemer/fix-linux-mouse#usb-mouse-disconnectsreconnects-every-minute-on-linux
Signed-off-by: Oleksandr Natalenko
---
drivers/hid/hid-ids.h| 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index eac0c54c5970
Just to highlight it after our conversation.
Signed-off-by: Oleksandr Natalenko
---
mm/madvise.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index edb7184f665c..70aeb54f3e1c 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1041,8 +1041,7
I couldn't compile it w/o this header.
Signed-off-by: Oleksandr Natalenko
---
mm/madvise.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/madvise.c b/mm/madvise.c
index 70aeb54f3e1c..9755340da157 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -25,6 +25,7 @@
#include
#include
"core" usually means something very different within the kernel land,
thus lets just follow the way it is handled in mutexes, rw_semaphores
etc and name common things as "_common".
Signed-off-by: Oleksandr Natalenko
---
mm/madvise.c | 14 +++---
1 file changed
runtime.
[1] https://lore.kernel.org/patchwork/patch/1012142/
Signed-off-by: Oleksandr Natalenko
---
mm/madvise.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/madvise.c b/mm/madvise.c
index 84f899b1b6da..e8f9c49794a3 100644
--- a/mm/madvise.c
+++ b/mm/madvis
your next iteration of process_madvise(), and then you'll Cc all the
people needed.
Thanks.
[1] https://lore.kernel.org/lkml/20190531064313.193437-1-minc...@kernel.org/
Oleksandr Natalenko (5):
mm: rename madvise_core to madvise_common
mm: revert madvise_inject_error line split
mm: include uio
Do the very same trick as we already do since 04f5866e41fb. KSM hints
will require locking mmap_sem for write since they modify vm_flags, so
for remote KSM hinting this additional check is needed.
Signed-off-by: Oleksandr Natalenko
---
mm/madvise.c | 3 +++
1 file changed, 3 insertions(+)
diff
ls each time we need
some amendment to existing interfaces. Yes, clone6(), I'm looking at
you :(.
In case of process_madvise() keep in mind it will be focused not only on
MADV_COLD, but also, potentially, on other MADV_ flags as well. I can
hardly imagine we'll add one syscall per each flag.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
5c1000740() GS:9ad01f60() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: c036efe5 CR3: 0008eb8a0005 CR4: 001606e0
Make sure to check if e577c8b64d ("mm, compaction: make sure we isolate
a valid PFN") fixes your issue. It is staged for 5.1.8, BTW.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
ed to roar.
>
> Then, do you mind sending a patch based upon this series to expose
> MADV_MERGEABLE to process_madvise? It will have the right description
> why you want to have such feature which I couldn't provide since I don't
> have enough material to write the motivation. And the patch also could
> include the logic to prevent coredump race, which is more proper since
> finally we need to hold mmap_sem write-side lock, finally.
> I will pick it up and will rebase since then.
Sure, I can. Would you really like to have it being based on this exact
revision, or I should wait till you deal with MADV_COLD & Co and re-iterate
this part again?
Thanks.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
On Fri, May 31, 2019 at 10:12:26PM +0900, Minchan Kim wrote:
> On Fri, May 31, 2019 at 09:04:20AM +0200, Oleksandr Natalenko wrote:
> > On Fri, May 31, 2019 at 03:43:11PM +0900, Minchan Kim wrote:
> > > This patch factor out madvise's core functionality so that upcoming
>
gt; + * MADV_NOHUGEPAGE - mark the given range as not worth being backed by
> + * transparent huge pages so the existing pages will not be
> + * coalesced into THP and new pages will not be allocated as THP.
> + * MADV_DONTDUMP - the application wants to prevent pages in the given range
> + * from being included in its core dump.
> + * MADV_DODUMP - cancel MADV_DONTDUMP: no longer exclude from core dump.
> + *
> + * return values:
> + * zero- success
> + * -EINVAL - start + len < 0, start is not page-aligned,
> + * "behavior" is not a valid value, or application
> + * is attempting to release locked or shared pages,
> + * or the specified address range includes file, Huge TLB,
> + * MAP_SHARED or VMPFNMAP range.
> + * -ENOMEM - addresses in the specified range are not currently
> + * mapped, or are outside the AS of the process.
> + * -EIO- an I/O error occurred while paging in data.
> + * -EBADF - map exists, but area maps something that isn't a file.
> + * -EAGAIN - a kernel resource was temporarily unavailable.
> + */
> +SYSCALL_DEFINE3(madvise, unsigned long, start, size_t, len_in, int, behavior)
> +{
> + return madvise_core(current, current->mm, start, len_in, behavior);
> +}
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
On Fri, May 24, 2019 at 01:31:46PM +0100, Mel Gorman wrote:
> On Fri, May 24, 2019 at 01:43:29PM +0200, Oleksandr Natalenko wrote:
> > > Please use the offset 0xb9
> > >
> > > addr2line -i -e /usr/src/linux/vmlinux `printf "0x%lX" $((0x$ADDR+0xb9))
>
On Fri, May 24, 2019 at 01:31:46PM +0100, Mel Gorman wrote:
> On Fri, May 24, 2019 at 01:43:29PM +0200, Oleksandr Natalenko wrote:
> > > Please use the offset 0xb9
> > >
> > > addr2line -i -e /usr/src/linux/vmlinux `printf "0x%lX" $((0x$ADDR+0xb9))
>
he CPU:
> > https://lkml.org/lkml/2019/5/9/225
> >
> > # ADDR=`nm /usr/src/linux/vmlinux | grep "t isolate_freepages_block\$"
> > | awk '{print $1}'`
> > # echo $ADDR
> > 812274f0
> > # addr2line -i -e /usr/src/linux/vmlinux `printf
ed)/stack
> > > [<0>] 0x
> > >
>
> As a workaround/in the meantime--I will add the following to lilo/grub:
> transparent_hugepage=never
>
> Justin
Cc'ing myself since i observe such a behaviour sometimes right after KVM
VM is launched. No luck with reproducing it on demand so far, though.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
es,
> >> > > > unsigned long flags);
> >> > > >
> >> > > > The syscall get pidfd to give hints to external process and
> >provides
> >> > > > pair of result/ranges vector arguments so that it could give
> >several
> >> > > > hints to each address range all at once.
> >> > > >
> >> > > > I guess others have different ideas about the naming of syscall
> >and options
> >> > > > so feel free to suggest better naming.
> >> > >
> >> > > Yes, all new syscalls making use of pidfds should be named
> >> > > pidfd_. So please make this pidfd_madvise.
> >> >
> >> > I don't have any particular preference but just wondering why pidfd
> >is
> >> > so special to have it as prefix of system call name.
> >>
> >> It's a whole new API to address processes. We already have
> >> clone(CLONE_PIDFD) and pidfd_send_signal() as you have seen since you
> >> exported pidfd_to_pid(). And we're going to have pidfd_open(). Your
> >> syscall works only with pidfds so it's tied to this api as well so it
> >> should follow the naming scheme. This also makes life easier for
> >> userspace and is consistent.
> >
> >Okay. I will change the API name at next revision.
> >Thanks.
>
> Thanks!
> Fwiw, there's been a similar patch by Oleksandr for pidfd_madvise I stumbled
> upon a few days back:
> https://gitlab.com/post-factum/pf-kernel/commit/0595f874a53fa898739ac315ddf208554d9dc897
>
> He wanted to be cc'ed but I forgot.
Thanks :).
FWIW, since this submission is essentially a continuation of our discussion
involving my earlier KSM submissions here, I won't move my gitlab branch
forward and will be happy to assist with what we have here, be it
pidfd_madvise() or a set or /proc files (or smth else).
>
> Christian
>
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
Hi.
On Tue, May 21, 2019 at 08:50:00AM +0200, Michal Hocko wrote:
> On Tue 21-05-19 08:36:28, Oleksandr Natalenko wrote:
> [...]
> > Regarding restricting the hints, I'm definitely interested in having
> > remote MADV_MERGEABLE/MADV_UNMERGEABLE. But, OTOH, doing it via
gt; return 0;
> +err_vc_screenbuf:
> + kfree(vc);
> + vc_cons[currcons].d = NULL;
> +err_vc:
> + console_unlock();
> + return -ENOMEM;
> +
> }
> console_initcall(con_init);
> ---
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
Hi.
On Tue, May 21, 2019 at 10:26:49AM +0900, Minchan Kim wrote:
> On Mon, May 20, 2019 at 04:26:33PM +0200, Oleksandr Natalenko wrote:
> > Hi.
> >
> > On Mon, May 20, 2019 at 12:52:51PM +0900, Minchan Kim wrote:
> > > This patch factor out madvise's core
currcons].d = NULL;
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index cd059a801662..c59b23f6e9ba 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1248,7 +1248,7 @@ static void fbcon_deinit(s
/syscalls.h | 2 +
> include/uapi/asm-generic/mman-common.h | 12 +
> include/uapi/asm-generic/unistd.h | 2 +
> kernel/signal.c| 2 +-
> kernel/sys_ni.c| 1 +
> mm/madvise.c | 600 +
> mm/swap.c | 43 ++
> mm/vmscan.c| 80 +++-
> 14 files changed, 680 insertions(+), 83 deletions(-)
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>
Please Cc me for the next iteration since I was working on the very same
thing recently [1].
Thank you.
[1] https://gitlab.com/post-factum/pf-kernel/commits/remote-madvise-v3
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
es will not be
> + * coalesced into THP and new pages will not be allocated as THP.
> + * MADV_DONTDUMP - the application wants to prevent pages in the given range
> + * from being included in its core dump.
> + * MADV_DODUMP - cancel MADV_DONTDUMP: no longer exclude from co
On Thu, May 16, 2019 at 04:20:13PM +0200, Oleksandr Natalenko wrote:
> > [...]
> > > @@ -2960,15 +2962,63 @@ static int proc_stack_depth(struct seq_file *m,
> > > struct pid_namespace *ns,
> > > static ssize_t madvise_write(struct file *file, const char __user *
Hi.
On Thu, May 16, 2019 at 12:00:24PM +0200, Jann Horn wrote:
> On Thu, May 16, 2019 at 11:43 AM Oleksandr Natalenko
> wrote:
> > Use previously introduced remote madvise knob to mark task's
> > anonymous memory as mergeable.
> >
> > To force merging tas
Hi.
On Thu, May 16, 2019 at 12:44:12PM +0200, Michal Hocko wrote:
> On Thu 16-05-19 11:42:29, Oleksandr Natalenko wrote:
> [...]
> > * to mark all the eligible VMAs as mergeable, use:
> >
> ># echo merge > /proc//madvise
> >
> > * to unmerge all th
ermail/linux/kernel/1905.1/02417.html
[3] http://lkml.iu.edu/hypermail/linux/kernel/1905.1/05076.html
Oleksandr Natalenko (5):
proc: introduce madvise placeholder
mm/ksm: introduce ksm_madvise_merge() helper
mm/ksm: introduce ksm_madvise_unmerge() helper
mm/ksm, proc: introduce r
Document respective /proc//madvise knob.
Signed-off-by: Oleksandr Natalenko
---
Documentation/filesystems/proc.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 66cad5c86171..17106e435bba 100644
Add a write-only /proc//madvise file to handle remote madvise
operations.
For now, this is just a soother that does nothing.
Signed-off-by: Oleksandr Natalenko
---
fs/proc/base.c | 20
1 file changed, 20 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index
ously introduced ksm_madvise_*() helpers
are used.
Signed-off-by: Oleksandr Natalenko
---
fs/proc/base.c | 52 +-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index f69532d6b74f..6677580080ed 100644
---
Move MADV_UNMERGEABLE part of ksm_madvise() into a dedicated helper
since it will be further used for unmerging VMAs forcibly.
This does not bring any functional changes.
Signed-off-by: Oleksandr Natalenko
---
include/linux/ksm.h | 2 ++
mm/ksm.c| 32
Move MADV_MERGEABLE part of ksm_madvise() into a dedicated helper since
it will be further used for marking VMAs to be merged forcibly.
This does not bring any functional changes.
Signed-off-by: Oleksandr Natalenko
---
include/linux/ksm.h | 2 ++
mm/ksm.c| 60
ious discussions please.
That way thinking of how a new API should be implemented (be it a sysfs
file or something else) should be easier and more visible.
Thanks.
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
Hi.
On Wed, May 15, 2019 at 08:53:11AM +0200, Michal Hocko wrote:
> On Wed 15-05-19 08:25:23, Oleksandr Natalenko wrote:
> [...]
> > > > Please make sure to describe a usecase that warrants adding a new
> > > > interface we have to maintain for ever.
> >
1 - 100 of 377 matches
Mail list logo
