Re: iowait v.s. idle accounting is "inconsistent" - iowait is too low

On 05/07/2019 12:38, Peter Zijlstra wrote: On Fri, Jul 05, 2019 at 12:25:46PM +0100, Alan Jenkins wrote: Hi, scheduler experts! My cpu "iowait" time appears to be reported incorrectly.  Do you know why this could happen? Because iowait is a magic random number that has no sa

Re: iowait v.s. idle accounting is "inconsistent" - iowait is too low

Hi, scheduler experts! My cpu "iowait" time appears to be reported incorrectly.  Do you know why this could happen? Doug helped me - it was he who noticed different behaviour on v4.15 vs v4.16 vs v4.17+.  So I have some confirmation of this.  I don't think Doug mentioned what hardware he ran

Re: NO_HZ_IDLE causes consistently low cpu "iowait" time (and higher cpu "idle" time)

On 03/07/2019 15:06, Doug Smythies wrote: On 2019.07.01 08:34 Alan Jenkins wrote: Hi Hi, I tried running a simple test: dd if=testfile iflag=direct bs=1M of=/dev/null With my default settings, `vmstat 10` shows something like 85% idle time to 15% iowait time. I have 4 CPUs, so this

NO_HZ_IDLE causes consistently low cpu "iowait" time (and higher cpu "idle" time)

Hi I tried running a simple test:     dd if=testfile iflag=direct bs=1M of=/dev/null With my default settings, `vmstat 10` shows something like 85% idle time to 15% iowait time. I have 4 CPUs, so this is much less than one CPU worth of iowait time. If I boot with "nohz=off", I see idle time

[PATCH v2] mm: avoid inconsistent "boosts" when updating the high and low watermarks

abka Signed-off-by: Vlastimil Babka Signed-off-by: Alan Jenkins Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") Acked-by: Mel Gorman --- Changes since v1: Use Vlastimil's suggested code. It is much c

[PATCH] mm: fix setting the high and low watermarks

Normal pages free 74597 min 9582 low 34505 high 36900 https://unix.stackexchange.com/questions/525674/my-low-and-high-watermarks-seem-higher-than-predicted-by-documentation-sysctl-vm/525687 Signed-off-by: Alan Jenkins Fixes: 1c30844d2dfe ("mm: reclaim sm

Re: [PATCH 10/25] vfs: fsinfo sample: Mount listing program [ver #13]

On 28/05/2019 16:12, David Howells wrote: Implement a program to demonstrate mount listing using the new fsinfo() syscall, Great. I understand this is only for demonstration, but IMO the output would be clearer with a few tweaks: for example: # ./test-mntinfo Can we have a header please?

Re: [PATCH 25/25] fsinfo: Add API documentation [ver #13]

On 28/05/2019 16:14, David Howells wrote: +Then there are attributes that convey information about the mount topology: + + * ``FSINFO_ATTR_MOUNT_INFO`` + +This struct-type attribute conveys information about a mount topology node +rather than a superblock. This includes the ID of the su

Re: [PATCH 09/25] vfs: Allow mount information to be queried by fsinfo() [ver #13]

On 28/05/2019 16:12, David Howells wrote: Allow mount information, including information about the topology tree to be queried with the fsinfo() system call. Usage of AT_FSINFO_MOUNTID_PATH allows overlapping mounts to be queried. To this end, four fsinfo() attributes are provided: (1) FSINF

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 21/09/2018 17:30, David Howells wrote: From: Al Viro Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be attached by move_mount(2). If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is not detached anymore, it won't be dissolved. move_mount(2) is adj

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 19/10/2018 23:36, David Howells wrote: Alan Jenkins wrote: # open_tree_clone 3 The reason EBUSY is returned is because propagate_mount_busy() is called by do_umount() with refcnt == 2, but mnt_count == 3: umount-3577 M=f8898a34 u=3 0x555 sp=__x64_sys_umount+0x12/0x15 the

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 19/10/2018 14:37, David Howells wrote: Alan Jenkins wrote: If I close() the mount FD "mfd", and then do "mount --move . /mnt", my printk() shows MNT_UMOUNT has been set. ( I guess fchdir() works more like openat(... , O_PATH) than dup() ). Then unmounting /mnt hangs, as

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

[resent, hopefully with slightly less formatting damage] On 17/10/2018 16:45, David Howells wrote: Alan Jenkins wrote: I agree. I'm happy to see this is using the same check as do_remount(). * change filesystem flags. dir should be a physical root of filesystem. * If you've mou

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

Hi David.  I think there's an outstanding point below, have you been thinking about it? On 07/10/2018 11:48, Alan Jenkins wrote: On 05/10/2018 19:24, Alan Jenkins wrote: On 21/09/2018 17:30, David Howells wrote: From: Al Viro Allow a detached tree created by open_tree(..., OPEN_TREE_

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On 17/10/2018 16:45, David Howells wrote: Alan Jenkins wrote: I agree. I'm happy to see this is using the same check as do_remount(). * change filesystem flags. dir should be a physical root of filesystem. * If you've mounted a non-root directory somewhere and want to do remou

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On 17/10/2018 15:35, Eric W. Biederman wrote: Alan Jenkins writes: On 17/10/2018 14:20, David Howells wrote: David Howells wrote: I should probably check that the picked point is actually a mountpoint. The root of the mount object at the path specified, that is, perhaps with something

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On 17/10/2018 14:20, David Howells wrote: David Howells wrote: I should probably check that the picked point is actually a mountpoint. The root of the mount object at the path specified, that is, perhaps with something like the attached. David I agree.  I'm happy to see this is using the

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On 13/10/2018 07:11, Al Viro wrote: On Fri, Oct 12, 2018 at 03:49:50PM +0100, Alan Jenkins wrote: +SYSCALL_DEFINE3(fspick, int, dfd, const char __user *, path, unsigned int, flags) +{ + struct fs_context *fc; + struct path target; + unsigned int lookup_flags; + int ret

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 12/10/2018 15:54, David Howells wrote: Alan Jenkins wrote: + open_tree_clone \ + move_mount \ I'll rename them to test-XXX if you're okay with that. David Yes, that's fine. Feel free to make adaptations you like.  I don't have anything planned for the

Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #12]

On 21/09/2018 17:34, David Howells wrote: Provide an fspick() system call that can be used to pick an existing mountpoint into an fs_context which can thereafter be used to reconfigure a superblock (equivalent of the superblock side of -o remount). This looks like: int fd = fspick(AT_FD

Re: [PATCH 03/33] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #11]

On 01/08/2018 16:24, David Howells wrote: From: Al Viro Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be attached by move_mount(2). If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is not detached anymore, it won't be dissolved. move_mount(2) is adju

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 10/10/2018 13:36, David Howells wrote: Alan Jenkins wrote: + * Copyright (C) 2017 Red Hat, Inc. All Rights Reserved. + * Written by David Howells (dhowe...@redhat.com) Do you want to update that and I can take them into my patchset? David Sure :).  I've attached a slightly up

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 11/10/2018 13:14, David Howells wrote: David Howells wrote: The reason that you can do this with open_tree()/move_mount() is that it allows you to create a mount tree (OPEN_TREE_CLONE) that has no namespace assignment, pass it through the namespace switch and then attach it inside the child

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 11/10/2018 10:17, David Howells wrote: Alan Jenkins wrote: # unshare --mount=private_mnt/child_ns --propagation=shared ls -l /proc/self/ns/mnt I think the problem is that the mount of the nsfs object done by unshare here pins the new mount namespace - but doesn't add the namesp

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 10/10/2018 14:02, David Howells wrote: The attached change seems to fix the lazy-umount problem. David --- diff --git a/fs/namespace.c b/fs/namespace.c index 5adeeea2a4d9..d43f0fa152e9 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2472,7 +2472,7 @@ static int do_move_mount(struct path

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 10/10/2018 13:31, David Howells wrote: Alan Jenkins wrote: # mount --move . /mnt is this calling move_mount(2) on your system? David No. That was an unpatched mount program, from util-linux. Alan

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 07/10/2018 11:48, Alan Jenkins wrote: On 05/10/2018 19:24, Alan Jenkins wrote: On 21/09/2018 17:30, David Howells wrote: From: Al Viro Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be attached by move_mount(2). If by the time of final fput() of OPEN_TREE_CLONE

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 05/10/2018 19:24, Alan Jenkins wrote: On 21/09/2018 17:30, David Howells wrote: From: Al Viro Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be attached by move_mount(2). If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is not detached anymore

Re: [PATCH 03/34] teach move_mount(2) to work with OPEN_TREE_CLONE [ver #12]

On 21/09/2018 17:30, David Howells wrote: From: Al Viro Allow a detached tree created by open_tree(..., OPEN_TREE_CLONE) to be attached by move_mount(2). If by the time of final fput() of OPEN_TREE_CLONE-opened file its tree is not detached anymore, it won't be dissolved. move_mount(2) is adj

Re: [PATCH 01/33] vfs: syscall: Add open_tree(2) to reference or clone a mount [ver #11]

On 02/08/18 22:51, David Howells wrote: Alan Jenkins wrote: Another closely-related limitation of `mount`, is that it can't atomically set the propagation type at mount time. I want to add a mount_setattr() too at some point: fd = open_tree(..., OPEN_TREE_

Re: [PATCH 01/33] vfs: syscall: Add open_tree(2) to reference or clone a mount [ver #11]

Hi I found this interesting, though I don't entirely follow the kernel mount/unmount code.  I had one puzzle about the code, and two questions which I was largely able to answer. On 01/08/18 16:24, David Howells wrote: +void dissolve_on_fput(struct vfsmount *mnt) +{ + namespace_lock();

Re: INFO: task hung in blk_queue_enter

> jbd2/sda1-8(PID=2271) is stuck waiting for journal commit operation. > I don't know how this thread is involved to this problem. It feels like it should be a necessary link in the chain. This is the filesystem underneath the loop device. If that hangs, we would expect the loop device to hang,

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

On 14/04/18 20:52, Jens Axboe wrote: On 4/14/18 1:46 PM, Alan Jenkins wrote: On 13/04/18 09:31, Johannes Thumshirn wrote: Hi Alan, On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote: # dd if=/dev/sda of=/dev/null iflag=direct & \ while killall -SIGUSR1 dd; do sleep 0.1;

Re: blktest for [PATCH v2] block: do not use interruptible wait anywhere

On 13/04/18 09:31, Johannes Thumshirn wrote: Hi Alan, On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote: # dd if=/dev/sda of=/dev/null iflag=direct & \ while killall -SIGUSR1 dd; do sleep 0.1; done & \ echo mem > /sys/power/state ; \ sleep 5; killall dd # stop afte

[PATCH v2] block: do not use interruptible wait anywhere

e Cc: sta...@vger.kernel.org Signed-off-by: Alan Jenkins --- v2: fix indentation block/blk-core.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index abcb8684ba67..1a762f3980f2 100644 --- a/block/blk-core.c +++ b/bloc

[PATCH] block: do not use interruptible wait anywhere

stop after 5 seconds The interruptible wait was added to blk_queue_enter in commit 3ef28e83ab15 ("block: generic request_queue reference counting"). Before then, the interruptible wait was only in blk-mq, but I don't think it could ever have been correct. Cc: sta...@vger.ke

Re: issues with unknown/new alias [retraction]

On 13/09/12 09:57, Christoph Jung wrote: Am 13.09.2012 10:49, schrieb Alan Jenkins: On 13/09/12 08:25, Christoph Jung wrote: Hello, I am from the company "Code Mercenaries GmbH" from Germany. We have some USB HID devices wich work with Linux. Since kernel version 2.6 our defaul

rtl8187: Invalid hwaddr! Using randomly generated MAC address

I've just acquired this buggy piece of hardware otherwise known as a NetGear WG111v2. I googled and eventually found an explanation in the form of source code here: . It seems linux rejects the hardware MAC address becaus

Re: Initramfs and TMPFS!

> On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote: > > Right, but it would be nice to have that option if initramfs > > using tmpfs becomes part of the kernel. > > But it's not needed so why add bloat? I'm not subscribed, so sorry if this doesn't fall into the original threa

Floppy drive LED

I compiled my kernel (2.6.11) with the floppy driver as a module - so it is not loaded on boot. When the floppy driver is laoded, the LED behaves as expected. When I unload it, the LED stays in its current state. So if I do this... # modprobe floppy; sleep 5; dd if=/dev/fd0 count=1 of=/dev/null

Re: RivaFB and GeForce FX

> I've tried adding the format and vpllB but I can't see any difference. ... > I'll get 2.6.6 (the version your patch applies to) and try with and > without your full patch. Hopefully I'll be able to see the difference. > Otherwise I might have to ask you to try the trivial and full patches > I'

Re: RivaFB and GeForce FX

> Dude you completely forgot the important parts of the code!! > Sorry I didn't reply to you in that previous e-mail before, I was > busy, but those vplB and 'format' stuff WAS important, without it, I > got strange distortions on screen and refreshes were "lagged"... The > ONLY things you can remo

RivaFB and GeForce FX

I asked on LKML about extending the list of supported cards for the rivafb driver to include GeForce/Quadro FX boards. I suspect the lack of response was down to two factors: a) Not addressing the maintainer b) Lack of a patch Hence this email! Without this patch, the only supported FX board is

Re: Re: RivaFB and GeForce FX

Query: register vpllB I have a question about your patch: you added chip->vpllB and chip->vpllB2 (presumably taken from the X driver). Do you know their purpose, and did you find them to be necessary or useful? Possible patch to add supported cards I discovered that since your patch, some ch

Re: 2.6.9 suspend-to-disk bug (during resume)

> > Try without preempt for an ugly workaround. > Check. ??? Sorry, I do not understand. My fault. I mean disabling preempt gets rid of the warnings. Ok, looks like I should enable PREEMPT here. But resume succeeds at the end, no? We'll probably need to fix those warnings, but driver model has big

Re: 2.6.9 suspend-to-disk bug (during resume)

On Thu, 2005-01-20 at 10:19 +0100, Rafael J. Wysocki wrote: > On Thursday, 20 of January 2005 09:49, Alan Jenkins wrote: > > On 20/01/05 08:48:02, Alan Jenkins wrote: > > I have noticed a similar message, and so has someone else on the list: > > > > http://g

Re: 2.6.9 suspend-to-disk bug (during resume)

On Thu, 2005-01-20 at 15:58 +0100, Pavel Machek wrote: > Hi! > > > > ACPI: PCI interrupt :00:02.7[C] -> GSI 10 (level, low) -> IRQ 10 > > bad: scheduling while atomic! > > [] schedule+0x4be/0x570 > > [] call_console_drivers+0x79/0x110 > > [] __mod_timer+0x177/0x190 > > [] schedule_timeout

2.6.9 suspend-to-disk bug (during resume)

On 20/01/05 08:48:02, Alan Jenkins wrote: I have noticed a similar message, and so has someone else on the list: http://groups-beta.google.com/group/fa.linux.kernel/browse_thread/thread/1bfcbbca2d508bb3/cb69d674510d215a?q=%22bad:+scheduling+while+atomic!%22+suspend&_done=%2Fgroup%2Ffa.linux.ke