[Bug 207817] kworker using a lots of cpu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.kernel.org/show_bug.cgi?id=207817

--- Comment #2 from bfoster@xxxxxxxxxx ---
On Thu, May 21, 2020 at 04:45:34PM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=207817
> 
> --- Comment #1 from Alexander Petrovsky (askjuise@xxxxxxxxx) ---
> After 1 day, it seems like some internal activity calm down kworker at 00:00
> UTC, it could be logrotate or smth else. But now, I'm observe the follow
> (seems
> like it has the same root cause):
> 

Note that you're reporting problems with a distro kernel and proprietary
hypervisor to an upstream mailing list (via an upstream bug tracker).
The feedback will likely be limited unless you can reproduce on an
upstream kernel.

In general, it's not really clear to me what you're reporting beyond the
writeback task using more CPU than anticipated. What is that based on?
What problematic functional or performance related behavior is observed?
If performance related, what exactly is the workload?

> #df -h
> Filesystem                     Size  Used Avail Use% Mounted on
> ...
> /dev/mapper/vg_logs-lv_varlog   38G  -30G   68G    - /var/log
> ...

I think we've had some upstream patches to fix underflows and such in
space reporting paths fairly recently, but I'm not sure off hand if
those are associated with any functional issues beyond indication of
potential corruption. This suggests you should probably run 'xfs_repair
-n' on this filesystem if you haven't already.

Brian

> 
> -- 
> You are receiving this mail because:
> You are watching the assignee of the bug.
>

-- 
You are receiving this mail because:
You are watching the assignee of the bug.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux