Bug 1202362 - udiskd high CPU usage with 4.0 git rc3
Summary: udiskd high CPU usage with 4.0 git rc3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1200124 1204053 (view as bug list)
Depends On:
Blocks: 1204627
TreeView+ depends on / blocked
 
Reported: 2015-03-16 13:26 UTC by spital
Modified: 2015-04-01 13:07 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-04-01 13:07:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description spital 2015-03-16 13:26:55 UTC
Description of problem:


https://lkml.org/lkml/2015/3/14/163


From	Torsten Kaiser <>
	

On Mon, Mar 9, 2015 at 12:30 AM, NeilBrown <neilb> wrote:
> On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor <prakash> wrote:
>
>> Hi,
>>
>> I noticed the udisks daemon (version 2.1.4) suddenly started using high
>> cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:
>>
>> 750f199ee8b578062341e6ddfe36c59ac8ff2dcb

I had the same problem upgrading from 4.0-rc1 to 4.0-rc3.
I have just finished bisecting and "fixing" it.

My bisect points to the same commit.

Looking at udisksd with strace sees a loop of polling and then
accessing several md related sysfs files.
The only file that udisksd monitors and was changes by that commit was
"sync_action".

If I revert this part of the commit, my system works normal again:

 static struct md_sysfs_entry md_scan_mode =
- __ATTR_PREALLOC(sync_action, S_IRUGO|S_IWUSR, action_show, action_store);
+ __ATTR(sync_action, S_IRUGO|S_IWUSR, action_show, action_store);
It seems that polling is broken for peralloc files.

The cause seems to be that kernfs_seq_show() updates ->event, while
the new sysfs_kf_read() does not.
So the polling will always trigger and udisksd goes into an inifinite
loop looking for changes that are not there.

I fixed my local system by copying the line "of->event =
atomic_read(&of->kn->attr.open->event);" from kernfs_seq_show() into
sysfs_kf_read(). (I also needed to move the definition of struct
kernfs_open_node from kernfs/file.c to kefs-internal.h)

udisksd now again behaves normal, but I'm not sending this change as a
patch, because I do not know about the locking and livetime of these
objects to evaluate, if that is really the correct fix.


Thanks,

Torsten

---------
[root@localhost ~]# uname -a
Linux mujpc 4.0.0-0.rc3.git0.1.fc22.x86_64 #1 SMP Mon Mar 9 13:36:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost ~]# top

top - 14:18:29 up 8 min,  2 users,  load average: 1.11, 0.91, 0.48
Tasks: 215 total,   2 running, 213 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.3 us, 15.3 sy,  0.0 ni, 74.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 16362728 total, 14351344 free,  1204720 used,   806664 buff/cache
KiB Swap: 18890748 total, 18890748 free,        0 used. 14890228 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                        
 1623 root      20   0  371856   8272   6624 R 100.0  0.1   8:24.98 udisksd

Comment 1 Michael Cronenworth 2015-03-17 15:23:56 UTC
There's a pending patch upstream that fixes this.

https://lkml.org/lkml/2015/3/15/173

Comment 2 Josh Boyer 2015-03-17 16:26:14 UTC
Yep, we know.  It should land in rawhide via the normal upstream paths.

Comment 3 Josh Boyer 2015-03-19 13:12:20 UTC
Upstream seems to be taking their time.  I added it in Fedora git.  It will be in the next build.

Comment 4 Thorsten Leemhuis 2015-03-19 15:18:21 UTC
*** Bug 1200124 has been marked as a duplicate of this bug. ***

Comment 5 Marius Vollmer 2015-03-20 11:46:14 UTC
*** Bug 1204053 has been marked as a duplicate of this bug. ***

Comment 6 Peter Trenholme 2015-03-20 20:51:03 UTC
Seems fixed in 4.0.0-0.rc4.git1.3.fc23.x86_64

Comment 7 Fedora Update System 2015-03-25 00:29:59 UTC
kernel-4.0.0-0.rc5.git1.3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/kernel-4.0.0-0.rc5.git1.3.fc22

Comment 8 spital 2015-03-26 09:32:26 UTC
It does not seem fixed for me with latest kernel


uname -a
Linux mujpc 4.0.0-0.rc4.git0.1.fc22.x86_64 #1 SMP Mon Mar 16 14:36:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

                                                                        
top -b -n 1 | head
top - 10:31:33 up  1:10,  2 users,  load average: 1.08, 1.08, 1.07
Tasks: 236 total,   2 running, 234 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.7 us, 15.4 sy,  0.1 ni, 72.8 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 16362724 total, 12651696 free,  1810728 used,  1900300 buff/cache
KiB Swap: 18890748 total, 18890748 free,        0 used. 14203704 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2227 root      20   0  372768   9208   6508 R 106.2  0.1  70:42.99 udisksd

Comment 9 Josh Boyer 2015-03-26 12:23:45 UTC
4.0.0-0.rc4.git0.1 is not expected to be fixed.  The fix is in later kernels.

Comment 10 Fedora Update System 2015-03-29 04:32:14 UTC
Package kernel-4.0.0-0.rc5.git1.3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-4.0.0-0.rc5.git1.3.fc22'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4839/kernel-4.0.0-0.rc5.git1.3.fc22
then log in and leave karma (feedback).

Comment 11 spital 2015-03-29 15:28:40 UTC
seems fine to me now ...

# uname -r
4.0.0-0.rc5.git1.3.fc22.x86_64

thanks :)

Comment 12 Josh Boyer 2015-04-01 13:07:46 UTC
This is fixed in the 4.0.0-0.rc5.git4.1.fc22 update.


Note You need to log in before you can comment on or make changes to this bug.