Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Things seems slower after going ~amd64 on gentoo-sources
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
h0ttentot
n00b
n00b


Joined: 20 Jun 2017
Posts: 16

PostPosted: Fri Aug 04, 2017 3:12 pm    Post subject: Things seems slower after going ~amd64 on gentoo-sources Reply with quote

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?
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5855

PostPosted: Fri Aug 04, 2017 4:18 pm    Post subject: Reply with quote

Post your .xinitrc. It sounds like you've caused a race condition by backgrounding too many processes.
Back to top
View user's profile Send private message
Cyker
Veteran
Veteran


Joined: 15 Jun 2006
Posts: 1746

PostPosted: Fri Aug 04, 2017 6:18 pm    Post subject: Reply with quote

'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.
Back to top
View user's profile Send private message
h0ttentot
n00b
n00b


Joined: 20 Jun 2017
Posts: 16

PostPosted: Fri Aug 04, 2017 7:13 pm    Post subject: Reply with quote

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


.xinitrc:
Code:
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:
Code:
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.
Back to top
View user's profile Send private message
Cyker
Veteran
Veteran


Joined: 15 Jun 2006
Posts: 1746

PostPosted: Fri Aug 04, 2017 9:55 pm    Post subject: Reply with quote

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! 8O
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13987

PostPosted: Sat Aug 05, 2017 12:07 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
h0ttentot
n00b
n00b


Joined: 20 Jun 2017
Posts: 16

PostPosted: Sat Aug 05, 2017 10:32 am    Post subject: Reply with quote

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 &" :lol: :lol:

This solved this issue for me. Thanks!

But things are still slower with the 4.12 kernel.
Back to top
View user's profile Send private message
duby2291
Guru
Guru


Joined: 17 Oct 2004
Posts: 583

PostPosted: Sat Aug 05, 2017 12:45 pm    Post subject: Re: Things seems slower after going ~amd64 on gentoo-sources Reply with quote

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.

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?


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.
Back to top
View user's profile Send private message
Juippisi
Developer
Developer


Joined: 30 Sep 2005
Posts: 355
Location: /home

PostPosted: Sun Aug 06, 2017 7:54 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Cyker
Veteran
Veteran


Joined: 15 Jun 2006
Posts: 1746

PostPosted: Mon Aug 07, 2017 11:18 am    Post subject: Reply with quote

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

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
Code:

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 :(

It seems that 4.12 has dropped the ball a bit on the filesystem side of things!
Back to top
View user's profile Send private message
h0ttentot
n00b
n00b


Joined: 20 Jun 2017
Posts: 16

PostPosted: Mon Aug 07, 2017 1:02 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
h0ttentot
n00b
n00b


Joined: 20 Jun 2017
Posts: 16

PostPosted: Mon Sep 04, 2017 11:37 pm    Post subject: Reply with quote

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. :lol:
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum