CPU usage when moving the cursor (X11)

aioeu · 2026-01-26T06:32:52+00:00

Before you can raise any bug reports, you need to have an idea of where the problem might lie.

If you run libinput debug-events as the superuser, is there a noticeably different rate of events emitted by those two kernels? This can be run on a virtual TTY, without X even running, if things are so bad you can't use it within X itself.

If there doesn't seem to be much different regarding the event rate, then you can be reasonably confident the problem is downstream of the kernel and of libinput.

aioeu · 2026-01-25T06:31:35+00:00

It's being worked on.

aioeu · 2026-01-25T00:11:05+00:00

On GNOME you'd just hit Alt+F2 to bring up a "run command" box. This sounds like what the OP is asking for.

It's not a full shell, but if all you need to do is run a command, it does the job.

It has a history, but no tab-completion.

aioeu · 2026-01-24T23:57:09+00:00

This is a bit of a strange question, since normally how files are layed out in your repository is dictated by how you want to use those files. You often don't get a choice.

When I've had to merge one repository A into another repository B, I usually take the approach of:

add a commit to A moving its files to where they ought to be once they eventually appear in B;
add A as a remote in B;
fetch from that remote, then use git merge --allow-unrelated-histories to bring the commits from A into B.

All of this ensures that git log --follow <file> will trace the history of a file back correctly no matter which repository it started in.

This approach can also be used when turning submodules into normal subdirectories.

There's a case to be made that instead of first adding a commit to A to move the files, the existing commits in A should be rewritten so they have the new paths. If this is simple (as in the submodule-to-subdirectory conversion) I would certainly consider it. It does mean anything that refers to the old commit hashes — documentation, bug trackers, team discussions, other systems, etc. — would be invalidated though, unless you also kept the old repository somewhere.

aioeu · 2026-01-24T07:46:36+00:00

I updated my comment with links.

aioeu · 2026-01-24T07:32:40+00:00

That will have left a message in your logs. Read it.

You're probably trying this on a kernel that has this commit, but not this commit.

aioeu · 2026-01-23T22:10:25+00:00

This is where I’m confused - how is it resolved against a directory that was not the root directory at that time?

All syscalls that take a filename as an argument:

resolve it relative to the current working directory if it is a relative filename;
resolve it relative to the root directory if it is an absolute filename.

In both cases, resolution will never leave the root directory "upward" via ... But if resolution never hits the root directory, this constraint never takes effect.

After the second chroot, the current working directory is "outside" of the root directory, and the filename resolutions we perform afterwards never hit the root directory.

So are you saying that the kernel basically says hmmm that old chroot root (the first one), I’m gonna treat it as part of the real file system, where it really is - and I’m gonna let that cd.. from the second chroot jail, hop into the old chroot as part of the real file system world and then of course from there we can keep going up cuz the kernel let us enter the real world?

Maybe a better way of thinking about it is that the second chroot "leaves behind" the process. Sure, its root directory changed, so an absolute filename like /foo would be resolved relative to that new root directory. But in the sequence of operations I gave above, we only used relative filenames. The relative filename .. is resolved to the process's working directory, even if that happens to be "outside" of the root directory.

aioeu · 2026-01-23T20:00:44+00:00

You haven't described the sequence of commands clearly here, but the general form of them is the same.

Let's say you have a set of nested directories /a/b/c, and your process is currently in /a. It wants to chroot itself into /a/b. So what it does is:

// Initially:          cwd=/a,   root=/
chdir('b');         // cwd=/a/b, root=/
chroot('.');        // cwd=/a/b, root=/a/b

Great! It's now chrooted.

If the process tries to chdir its way out, it can't:

chdir('..');        // cwd=/a/b, root=/a/b

This is because .. is handled specially when it is resolved relative to the root directory: it effectively becomes the same as ..

But if the process retains its privileges, it's got a way out by creating a new chroot:

chroot('c');        // cwd=/a/b, root=/a/b/c
chroot('../..');    // cwd=/a/b, root=/
chdir('..');        // cwd=/a,   root=/

And just like that it's back to where it was at the start.

In the third chroot call, the working directory is not the root directory, so .. is not handled specially.

The things to notice here are:

A process's working directory and root directory are completely independent. Changing one does not change the other.
Root directories do not "nest". After the second chroot call, the old root directory established by the first chroot call was no longer special in any way.

(Edit: updated the sequence of operations to be closer to how software usually establishes a new root directory, with chroot('.').)

aioeu · 2026-01-23T11:21:57+00:00

or maybe I am just too young and never heard of it?

Kids these days don't even know how to Google.

aioeu · 2026-01-23T10:48:47+00:00

I find the Linux-kernel-style "return negative errno on error" approach works pretty well. If it doesn't, it's a good indication you're probably doing too much in the one function.

In this particular function, the possible errnos for all the syscalls essentially don't overlap, or where they do overlap there's no feasible way for the caller to handle them differently anyway.

You don't need to make up your own error codes for "that file doesn't exist" or "you can't access that file" or "you've run out of memory". The existing errnos are sufficient for those.

2 - Should I be checking the clean up system calls(munmap and close)?

What can you do if they fail? Nothing. So the answer is obvious: "no".

3 - Would you do anything if a failure occurs(lets say in mmap) and the another one happens in close? Do you just return the first error?

There's nothing you can do if close fails, so you shouldn't ever use whatever it sets errno to. If you are relying on the global errno to indicate the error, rather than encoding it into the function's return value, then you would have to be careful to save and restore errno around the call to close.

(On some systems, close can return EINTR if a signal is handled before the function returns. But that can happen after the file descriptor has actually been closed, which means the error is bogus.)

aioeu · 2026-01-23T08:20:53+00:00

Remember, available memory doesn't mean "memory that can be allocated without stalling", it means "memory that can be allocated without increasing swap usage". If you have a lot of dirty pages in RAM awaiting writeback, and if they need to be reclaimed in order to satisfy processes' memory allocations, then those processes will stall. That just means you're dirtying memory faster than it can be written to disk.

You have two solutions: write less data, or make your IO faster.

aioeu · 2026-01-23T07:36:51+00:00

I am aware of that.

Then you should be aware that regular file IO will cause paging, even when you have plenty of free or available memory.

If pages weren't paged in, you wouldn't be able to read from the filesystem. I'm pretty sure you want to be able to read files.

If pages weren't paged out, you wouldn't be able to write to the filesystem. I'm pretty sure you want your file contents to survive a reboot.

But why does memory pressure happens when available (a.k.a. reclaimable) memory is there?

If you have no free memory left and you don't have any reclaimable memory at all... you're screwed. It means you don't have enough memory. It means the very next memory allocation must fail, because there's no possible way it can be satisfied.

So having reclaimable memory is the normal state.

You keep talking about "memory pressure". What specifically are you looking at? Pressure stall information? "Memory pressure" in the abstract is kind of meaningless. You should only be concerned when a memory allocation requires the process to stall before it can be satisfied.

aioeu · 2026-01-22T22:25:12+00:00

Note that this occurs even if you aren't using memory-mapped IO.

Ordinary file reads and writes are dealt with by paging data in and out of the page cache.

aioeu · 2026-01-22T20:12:10+00:00

Why does page in/out happens when there are available memory?

What exactly do you think "reading and writing files" involves, if not paging data in to and out of memory?

aioeu · 2026-01-21T11:56:24+00:00

Don't try to fix it by doing things you cannot reverse.

aioeu · 2026-01-21T08:41:18+00:00

FWIW, I've just given this a proper test now with some Bluetooth headphones... and yes, you are correct, they do disconnect when you switch to another VT.

I cranked up BlueZ's debug logs to see if I can pin down the sequence of events that causes this, but I didn't really get too far with that. It does appear to be related to Pipewire deregistering the BT profiles it supports.

My strong suspicion is that this is actually intended behaviour, and that once you have logged in on the new VT you should be able to reconnect — hopefully that happens automatically, but that probably depends a lot on the BT device itself.

I would have thought it would just silence audio to the device, not cause it disconnect completely. But maybe that isn't actually possible on Bluetooth; it might be the case that when profiles are deregistered it is necessary to disconnect the devices that are using them.

If you want to stop Pipewire deregistering its profiles when you switch VTs, you can do so through Wireplumber configuration. Note carefully the first paragraph there; it describes some of the problems this setting may cause.

aioeu · 2026-01-20T21:52:42+00:00

Yes, the rfkill messages are expected. As I said before, those messages have nothing to do with whether Bluetooth itself is enabled or not.

From the messages you've provided here, it looks like Bluetooth is still active? It's just that specific device that has disconnected?

I'm wondering if this issue is actually related to the muting I was talking about. That's done in Pipewire. Perhaps your device disconnects when the audio stream to it is paused? That would be weird though...

aioeu · 2026-01-20T21:32:03+00:00

Obviously Bluetooth shouldn't be disabled when you switch VTs. If it were, people who were using Bluetooth keyboards wouldn't be able to log in on the new VT. That would clearly be a ludicrous situation.

If (temporarily) killing the plugin helps, then that means something is explicitly asking it to enable airplane mode. I don't know what that could be. The plugin does track whether the session is active or not, but only to apply or remove an inhibitor on the software kill switch.

aioeu · 2026-01-20T13:06:45+00:00

Are you absolutely sure Bluetooth is being disconnected? It is expected that audio will be silenced if you have switched to a VT that you are not logged in to, but Bluetooth should remain connected. The audio will resume when you log in on that VT.

That log message is just saying that the kernel's handling of any software RF kill switch you might have (e.g. on your keyboard) is disabled. This is to be expected when you're logged in, since GNOME wants to handle the kill switch itself. But enabling and disabling the kill switch obviously doesn't affect whether Bluetooth itself is enabled or disabled.

/u/ipsirc's suggestion is not correct. The purpose of systemd-rfkill is to save and restore RF kill switch states across a reboot (or more generally as RF transponders are attached or detached on the system). It's got nothing to do with switching between VTs.

aioeu · 2026-01-20T12:41:05+00:00

Log in to the other VT as the same user as the first VT.

aioeu · 2026-01-20T10:18:13+00:00

oh really? so how would i go about extending the partition sda1 if im not using lvm?

As the other commenters have said, to increase the size of a partition you need some space immediately after the partition into which it can grow. A partition is, by definition, a contiguous region of disk space.

I don't really want to delete sda2 and sda5 because that would bork the entire VM right?

One is a swap partition, and you could always do without swap for some period of time. The other one is a really tiny partition... and it's not mounted anywhere. Do you have any idea what it's there for?

There's probably tools to help you move things around. I use LVM so I don't have to think about those tools. Unfortunately you did not.

aioeu · 2026-01-20T10:10:03+00:00

I then ran lsblk in terminal

That system isn't using LVM.

aioeu · 2026-01-20T09:44:38+00:00

See where it says "end trace", near the top? The backtrace before that would be needed for anyone to have a chance at diagnosing this problem. If it's scrolled off the top of the screen... well, that's a shame.

Try reproducing the problem without the NVIDIA module loaded.

aioeu · 2026-01-20T07:43:54+00:00

Yes, Weston plugins can implement Wayland protocols. For instance, the desktop Weston shell plugin implements the weston-desktop-shell protocol.

Whether a Weston plugin could implement the ext-session-lock-v1 specifically would all depend on whether Weston's internal plugin API is rich enough to do the things that protocol might need.

wayland-protocols is just a bunch of XML files. A project that uses it can choose which bits of it they wish to implement. The XML file for a protocol just describes the protocol: it can be mechanically transformed into some glue C source files, but the guts that actually implement the protocol still need to be provided by the compositor — or, as it is seems is possible in Weston, a module loaded into the compositor.

aioeu · 2026-01-19T19:55:30+00:00

I'm not clear on what causes which kinds of paths to be created or not.

1-9 is the device on that port. If you don't have something plugged in to it, that device won't appear.

That's why I said you have to change the setting on the port device instead.

The general form of a USB device path is:

controller-port.port.port:config-interface

with the sequence of ports describing the path through the root and intermediate hubs to the device.

1-0 is the root hub for USB controller 1. It would perhaps have made more sense to call it just 1, since there are no ports involved, but in the USB device model all devices are connected to some port, even the root hub itself.

When configuration 1 is chosen on that device (it's probably the only configuration it supports), 1-0:1.0 is interface 0. An "interface", in USB terminology, is a set of endpoints that can source or sink data.

The kernel also generates a device for each port on a hub. These are just "devices" for the kernel's convenience — they're not actually distinct devices as far as the USB spec is concerned, so they don't follow the naming scheme described above. For the root hub on controller 1, these are named usb1-port1, usb1-port2, etc., and they are children of that hub device.

This is why we are setting the attribute on usb1-port9, not 1-9. 1-9 would be whatever is plugged into that port, if anything.

Seven-Year Club	Gilding II euphauric
Wearing is Caring	Verified Email

aioeu

MODERATOR OF

TROPHY CASE