# Things seems slower after going ~amd64 on gentoo-sources

## h0ttentot

I bought a new GPU (Radeon RX 550), so to use it i updated the kernel to 4.12.4 using ~amd64.

However, the system seems to have slowed down a little.

My .xinitrc has "xrdb -m .Xresources" to customize my urxvt.

When i type startx, my window manager (bspwm) launches two terminals on my first workspace. They are starting not customized, with white background, scrollbar and horrible font, but when i open new ones after that, they're already customized. It's like the command on .xinitrc is taking it's time to work.

Sometimes when i list files on directories on the terminal (using tab completion or ls), they take some miliseconds to list.

When i open ranger (terminal file browser) for the first time, it takes it's time to read the content of some directories too.

Maybe the slower listing files/directories thing is in my head, but i don't think so. I'm sure the "xrdb -m .Xresources" isn't since i never needed to put "sleep 2s &" after "xrdb -m .Xresources &" to wait a little for it to work and sometimes it doesn't work even after waiting 2s, but when i launch new terminals, they are fine.

Some info:

glxinfo: https://pastebin.com/qxXYPeTL

dmesg: https://pastebin.com/fSEQBDHE

Xorg.0.log: https://pastebin.com/y7LQGfzB

What could be happening?

----------

## Ant P.

Post your .xinitrc. It sounds like you've caused a race condition by backgrounding too many processes.

----------

## Cyker

's funny you mention this... I've noticed that kind of thing too - Little extra barely noticeable delays when loading something for the first time, be it a terminal, a console command or even accessing a directory I hadn't accessed before - but assumed it was a side-effect of the massive portage pile I just pushed through.

If you only got it after updating to 4.12, I'm now wondering if there's been some change in the way the kernel does caching/buffering and scheduling that is causing this - There seem to have been a lot of additions and changes in that area since the 4.8 I was on previously.

----------

## h0ttentot

 *Ant P. wrote:*   

> Post your .xinitrc. It sounds like you've caused a race condition by backgrounding too many processes.

 

.xinitrc:

```
export SOLARIZED=true

xrdb -merge ~/.Xresources &

xsetroot -cursor_name left_ptr &

numlockx &

feh --randomize --bg-scale ~/.wp/* &

xset +fp /home/cris/.fonts &

xset fp rehash &

sleep 1s &

exec bspwm

```

After this, bspwmrc calls the terminals and the taskbar:

bspwmrc:

```
sleep 2s &

$HOME/.config/polybar/launch.sh &

sleep 2s &

urxvt -name cmus -e cmus &

sleep 2s &

urxvt -name rtorrent -e rtorrent &
```

I don't think it has nothing to do with this since nothing changed from before, just the kernel.

 *Cyker wrote:*   

> 's funny you mention this... I've noticed that kind of thing too - Little extra barely noticeable delays when loading something for the first time, be it a terminal, a console command or even accessing a directory I hadn't accessed before - but assumed it was a side-effect of the massive portage pile I just pushed through.
> 
> If you only got it after updating to 4.12, I'm now wondering if there's been some change in the way the kernel does caching/buffering and scheduling that is causing this - There seem to have been a lot of additions and changes in that area since the 4.8 I was on previously.

 

Yeah, before i was at 4.9.34 and it was fast as always. I think it's something with the new kernel.

----------

## Cyker

Well hopefully 4.13 will be out before too long; There seems to be some nasty bugs in 4.12 that have sneaked through - In the 2-3 days I've been running it I now have a 70MB log full of btrfs warnings!  :Shocked: 

----------

## Hu

I think you need to think this through a bit more, h0ttentot.  A trailing ampersand places the command in the background instead of waiting for it to finish.  You are backgrounding instances of sleep, so the script continues without waiting for the sleep to finish sleeping.  This means that the sleep imposes only the minimal delay required to fork a process that will later exec sleep, not the full delay you told it to sleep.

I suggest removing the sleep entirely, moving all the commands that must be backgrounded to the end, and adding wait after starting all the short-lived background commands, but before starting any of the long-lived background commands.

----------

## h0ttentot

 *Hu wrote:*   

> I think you need to think this through a bit more, h0ttentot.  A trailing ampersand places the command in the background instead of waiting for it to finish.  You are backgrounding instances of sleep, so the script continues without waiting for the sleep to finish sleeping.  This means that the sleep imposes only the minimal delay required to fork a process that will later exec sleep, not the full delay you told it to sleep.
> 
> I suggest removing the sleep entirely, moving all the commands that must be backgrounded to the end, and adding wait after starting all the short-lived background commands, but before starting any of the long-lived background commands.

 

You are right. Thanks.

I don't know what was on my mind by using "sleep 2s &"  :Laughing:   :Laughing: 

This solved this issue for me. Thanks!

But things are still slower with the 4.12 kernel.

----------

## duby2291

 *h0ttentot wrote:*   

> I bought a new GPU (Radeon RX 550), so to use it i updated the kernel to 4.12.4 using ~amd64.
> 
> However, the system seems to have slowed down a little.
> 
> My .xinitrc has "xrdb -m .Xresources" to customize my urxvt.
> ...

 

That doesn't sound graphical at all to to me. The slowdown "feels" more like an IO bottlneck from your description of what is happening.

----------

## Juippisi

Did you change I/O schedulers when upgrading? I think it takes some effort to get BFQ working with 4.12.

EDIT: Apparently ext4 has been buggy in 4.12, 

https://lkml.org/lkml/2017/8/6/219

----------

## Cyker

It's not just ext4... I have many 10's of MB of

```

kernel: [235827.667067] ------------[ cut here ]------------

kernel: [235827.667078] WARNING: CPU: 0 PID: 16681 at fs/btrfs/backref.c:1392 find_parent_nodes+0x763/0x890

kernel: [235827.667078] Modules linked in: f71882fg rc_total_media_in_hand_02 si2157 amdkfd radeon si2168 i2c_algo_bit r820t rtl2832 i2c_mux 

kernel: [235827.667106] CPU: 0 PID: 16681 Comm: qbittorrent Tainted: G        W       4.12.4-gentoo #2

kernel: [235827.667107] Hardware name: MSI MS-7721/A88XM-E45 (MS-7721), BIOS V25.6 12/15/2014

kernel: [235827.667108] task: ffff88041d21ae00 task.stack: ffffc9000bb18000

kernel: [235827.667111] RIP: 0010:find_parent_nodes+0x763/0x890

kernel: [235827.667112] RSP: 0018:ffffc9000bb1bbf0 EFLAGS: 00010286

kernel: [235827.667113] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000005301854

kernel: [235827.667114] RDX: ffff8802cd0d0230 RSI: ffffc9000bb1bc60 RDI: ffffc9000bb1bc60

kernel: [235827.667115] RBP: ffffc9000bb1bcc0 R08: 000000000001f720 R09: ffffffff8129c39a

kernel: [235827.667116] R10: ffffea000c108dc0 R11: ffff880000000000 R12: ffff880304237c60

kernel: [235827.667117] R13: ffff88041efaf438 R14: ffff880304237500 R15: ffff8802cd0d0230

kernel: [235827.667118] FS:  00007f5cec9a9700(0000) GS:ffff88043ec00000(0000) knlGS:0000000000000000

kernel: [235827.667120] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

kernel: [235827.667121] CR2: 00007f206d6f0c60 CR3: 0000000370fdc000 CR4: 00000000000406f0

kernel: [235827.667121] Call Trace:

kernel: [235827.667125]  btrfs_check_shared+0xf0/0x190

kernel: [235827.667128]  extent_fiemap+0x59c/0x710

kernel: [235827.667131]  ? btrfs_get_extent+0xa20/0xa20

kernel: [235827.667132]  btrfs_fiemap+0x4d/0x60

kernel: [235827.667135]  do_vfs_ioctl+0x453/0x5c0

kernel: [235827.667137]  SyS_ioctl+0x47/0x80

kernel: [235827.667141]  entry_SYSCALL_64_fastpath+0x13/0x94

kernel: [235827.667142] RIP: 0033:0x7f5d061a0377

kernel: [235827.667143] RSP: 002b:00007f5cec9a7588 EFLAGS: 00000246 ORIG_RAX: 0000000000000010

kernel: [235827.667145] RAX: ffffffffffffffda RBX: 00007f5cd4008960 RCX: 00007f5d061a0377

kernel: [235827.667145] RDX: 00007f5cec9a7590 RSI: 00000000c020660b RDI: 0000000000000038

kernel: [235827.667146] RBP: 0000000002817a28 R08: 0000000031aba88e R09: 0000000000000000

kernel: [235827.667147] R10: 0015f632cba27c4b R11: 0000000000000246 R12: 0000000002817a20

kernel: [235827.667148] R13: 0000000002817a58 R14: 0000000000000061 R15: 0000000002817a20

kernel: [235827.667149] Code: 00 48 89 c2 48 8b 42 10 48 85 c0 75 f4 49 8b 47 38 48 89 42 10 48 c7 45 80 00 00 00 00 e9 d0 fe ff ff 85 c0 75 ?

kernel: [235827.667173] ---[ end trace dddb742a622876c0 ]---

```

and

```

BTRFS warning (device sde): unhandled fiemap cache detected: offset=94158848 phys=43500809527296 len=2310144 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=383336448 phys=55830804393984 len=966656 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=23062752 phys=44341940447456 len=530208 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=68205936 phys=44692540276080 len=475792 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=211827138 phys=59042235718082 len=591422 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=396460032 phys=55829690679296 len=425984 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=23603424 phys=44341940988128 len=513824 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=3878670877 phys=44582413967901 len=181231075 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=94814208 phys=43500810182656 len=1654784 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=902709248 phys=44678684037120 len=82096128 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=399032320 phys=55832732012544 len=999424 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=96108544 phys=43500811476992 len=360448 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=53706798 phys=43431399161902 len=1720274 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=168583332 phys=44335869747364 len=99852124 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=537067520 phys=53111053758464 len=327680 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=68345751 phys=44693281996695 len=335977 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=209862656 phys=43495653257216 len=4046848 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=63824395 phys=44484470202891 len=663029 flags=0x0

BTRFS warning (device sde): unhandled fiemap cache detected: offset=223410814 phys=44332349192830 len=45024642 flags=0x0

```

filling my logs with 4.12  :Sad: 

It seems that 4.12 has dropped the ball a bit on the filesystem side of things!

----------

## h0ttentot

 *Juippisi wrote:*   

> Did you change I/O schedulers when upgrading? I think it takes some effort to get BFQ working with 4.12.
> 
> EDIT: Apparently ext4 has been buggy in 4.12, 
> 
> https://lkml.org/lkml/2017/8/6/219

 

Didn't change anything at all. Let's wait and see if 4.13 will fix things.

----------

## h0ttentot

Anybody on 4.13? I think the issue is solved, but can anyone confirm?

I'm not quite sure because i got used to it so maybe it's placebo.  :Laughing: 

----------

