Hi,
let me add some additional data point(s):
After some testing on different machines and with different kernel types
it looks like this problem is exclusive to MP kernels. This also when
running a MP kernel on a single processor machine actually (tested on an
AlphaServer 800 5/400 w/EV56).
Running an SP kernel does not trigger that problem.
I posted a diff between the -alpha-generic and -alpha-smp kernel
configurations on [1].
[1]: https://pastebin.com/AwZQjHD9
On 22.05.23 11:37, John Paul Adrian Glaubitz wrote:
Hello Frank!
On Mon, 2023-05-22 at 11:34 +0200, Frank Scheiner wrote:
Maybe someone on linux-alpha has an idea what could be the reason?
Try reproducing it with libcgroup to see if it's a systemd or a kernel bug:
https://wiki.archlinux.org/title/cgroups#Examples
Took me a while to get back to this and actually get it working...
Following misc. examples and manpages (e.g. [2] and [3]) I did the
following to test cgroup functionality with System V init installed and
running instead of systemd:
```
root@ds25:~# uname -a
Linux ds25 6.3.0-1-alpha-smp #1 SMP Debian 6.3.7-1 (2023-06-12) alpha
GNU/Linux
root@ds25:~# mount
[...]
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755,inode64)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
[...]
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,relatime,rdma)
cgroup on /sys/fs/cgroup/misc type cgroup (rw,relatime,misc)
root@ds25:~# CGROUP=/sys/fs/cgroup
root@ds25:~# mkdir $CGROUP/red
root@ds25:~# mount -t cgroup -o cpuset red $CGROUP/red
root@ds25:~# mkdir -p $CGROUP/red/shells/bash
root@ds25:~# chown root:root $CGROUP/red/shells/bash/*
root@ds25:~# id johndoe
uid=1001(johndoe) gid=1001(johndoe) groups=1001(johndoe),100(users)
root@ds25:~# chown root:johndoe $CGROUP/red/shells/bash/tasks
root@ds25:~# echo $(cgget -n -v -r cpuset.mems /) >
$CGROUP/red/shells/cpuset.mems
root@ds25:~# echo $(cgget -n -v -r cpuset.cpus /) >
$CGROUP/red/shells/cpuset.cpus
root@ds25:~# echo 0 > $CGROUP/red/shells/bash/cpuset.mems
root@ds25:~# echo 0 > $CGROUP/red/shells/bash/cpuset.cpus
root@ds25:~# cat /proc/self/cgroup
13:misc:/
12:rdma:/
11:pids:/
10:net_prio:/
9:perf_event:/
8:net_cls:/
7:freezer:/
6:devices:/
5:memory:/
4:blkio:/
3:cpuacct:/
2:cpu:/
1:cpuset:/
root@ds25:~# echo $$
1496
root@ds25:~# cgexec -g cpuset:shells/bash bash
root@ds25:~# echo $$
1695
root@ds25:~# cat /proc/self/cgroup
13:misc:/
[...]
2:cpu:/
1:cpuset:/shells/bash
```
[2]:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch-using_control_groups
[3]: https://wiki.archlinux.org/title/cgroups#Examples
I then ran `7za b` in that shell and though `7za` executes two threads
assuming it has access to both CPUs, `htop` showed both of them running
on the first processor only. So it looks like at least this part of the
cgroup functionality is working with Linux 6.3.0-1 from Debian when
using System V init.
So it could be that this problem is only triggered with one or multiple
specific controller(s). But I don't exactly know how to determine the
used controller(s) for target "graphical.target" - where this seems to
happen according to (see more details on [4]):
```
[...]
[ 11.864251] systemd[1]: Queued start job for default target
graphical.target.
[ 11.958978] CPU 1
[ 11.958978] systemd(1): Instruction fault 4
[...]
```
[4]: https://lists.debian.org/debian-alpha/2023/05/msg00012.html
Cheers,
Frank
