Am Freitag, 22. Juni 2018, 14:25:52 CEST schrieb Patrick Shanahan:

* Axel Braun [06-22-18 07:53]:

...

Hi again,

I still face an issue on the Desktop I have converted from Leap 42.3 to 15. Desktop (KDE) is partly unresponsive for 2 Minutes, full load on both CPU cores, most likely due to disk-activities (baloo....). Not even CRTL-ESC is working during this time.

Is there any tweak to make it more responsive? - Different kind of Kernel or Kernel scheduler? Currently running the default kernel. - any idea to reduce the priority of baloo in order to reduce the disk activities?

Dual Core Intel G4400@3.3 GHz, 8G RAM, MSI H110M PRO-D Motherboard Any additional information needed?

have you tried top or htop to see what process(s) is stalling your system rather than "most likely" as you leave us shooting in the dark.

you are right, top gives a better overview than KDE process monitor At the top of the list, esp, when there is no response from the desktop, is plasmashell and kwin_X11. Graphics is an Intel i915 - is this maybe related? southpole: # lspci -s 00:02.0 -v 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7996 Flags: bus master, fast devsel, latency 0, IRQ 122 Memory at de000000 (64-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Kernel driver in use: i915 Kernel modules: i915 Best, Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Am Freitag, 22. Juni 2018, 16:58:32 CEST schrieb Patrick Shanahan: [...]

...

Graphics is an Intel i915 - is this maybe related? southpole: # lspci -s 00:02.0 -v 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller])

Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7996 Flags: bus master, fast devsel, latency 0, IRQ 122 Memory at de000000 (64-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Kernel driver in use: i915 Kernel modules: i915

so it is probably not akonadi or baloo which is causing your system to crawl, but plasmascreen.

with the hint from Carlos to use iotop: baloo_file_extractor works hard on the disk (and, as Gertjan mentioned, the old index DB was already removed), but the real problem comes from plasmashell

not a solution but will probably releave your system, in a terminal window: kquitapp5 plasmashell && sleep 2 && kstart plasmashell & disown && sleep 10 && exit

that is one line.

Since I had run this command it seems that plasmashell is more responsive. No more breals for minutes....

I would guess you are having problems with the drivers for your video card. I cannot help you there.

Video driver is the i915 Intel driver. No special boot parameter. Can this 'communication' between video driver and plasmashell be monitored somehow? Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Am Samstag, 23. Juni 2018, 14:35:39 CEST schrieb Patrick Shanahan:

* Axel Braun [06-23-18 08:21]:

...

Am Freitag, 22. Juni 2018, 16:58:32 CEST schrieb Patrick Shanahan:

[...]

...

...

Graphics is an Intel i915 - is this maybe related? southpole: # lspci -s 00:02.0 -v 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller])

Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7996 Flags: bus master, fast devsel, latency 0, IRQ 122 Memory at de000000 (64-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Kernel driver in use: i915 Kernel modules: i915

so it is probably not akonadi or baloo which is causing your system to crawl, but plasmascreen.

with the hint from Carlos to use iotop: baloo_file_extractor works hard on the disk (and, as Gertjan mentioned, the old index DB was already removed), but the real problem comes from plasmashell

so perhaps you need to examine baloo's configuration or wait for baloo to finish rebuilding it's indexes

you do have the option to suspend the indexing to rule out, or not, baloo as the problem.

As written, ballo seems not to be the problem in that case.

...

...

not a solution but will probably releave your system, in a terminal

window: kquitapp5 plasmashell && sleep 2 && kstart plasmashell & disown && sleep 10 && exit

that is one line.

Since I had run this command it seems that plasmashell is more responsive. No more breals for minutes....

does "minutes..." mean you have relief or only momentary and then the same lack of system response?

if this provides relief, it would seem that baloo was not really the problem but the video drivers.

After I played some more with the command, it is _not_ giving durable relief. It still needs a minute or so to open a new window, like dolphin. Inside e.g. the terminal, output of top refreshes regulary

...

...

I would guess you are having problems with the drivers for your video card. I cannot help you there.

Video driver is the i915 Intel driver. No special boot parameter. Can this 'communication' between video driver and plasmashell be monitored somehow?

have we determined that video is the problem or are we chasing a path which will not provide a solution?

understanding that *you* want to solve your problems and gain knowledge while doing so, your hesitation to provide requested details is not making others attempts to provide you solution any easier. please be more forthcoming.

Hm, I though I have phrased that above, sorry itf that did not come through properly. So yes, it looks it is video/plasmashell. Even the text while typing is partly stalled for some seconds, until it arrives Thanks Axeö -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Am Samstag, 23. Juni 2018, 18:11:00 CEST schrieb Patrick Shanahan:

...

Hm, I though I have phrased that above, sorry itf that did not come through properly. So yes, it looks it is video/plasmashell. Even the text while typing is partly stalled for some seconds, until it arrives

and what does top show. what is consuming your cpu?

As written before, plasmashell, kwin_X11 and X Additionally I have posted the output of iotop, maybe that helps as well: http://paste.opensuse.org/48571917 Each Thread shows 0 Disk write, but the summary line on top says 2.55 M/s. Thats strange, IMHO. Additionally, how to interpret IO? Does it mean that the CPU is 99.99% of the time dedicated to that process busy waiting, not computing? Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 2018-06-23 18:51, Axel Braun wrote:

Am Samstag, 23. Juni 2018, 18:11:00 CEST schrieb Patrick Shanahan:

...

...

Hm, I though I have phrased that above, sorry itf that did not come through properly. So yes, it looks it is video/plasmashell. Even the text while typing is partly stalled for some seconds, until it arrives

and what does top show. what is consuming your cpu?

As written before, plasmashell, kwin_X11 and X

Additionally I have posted the output of iotop, maybe that helps as well: http://paste.opensuse.org/48571917

Each Thread shows 0 Disk write, but the summary line on top says 2.55 M/s. Thats strange, IMHO.

Additionally, how to interpret IO? Does it mean that the CPU is 99.99% of the time dedicated to that process busy waiting, not computing?

In that photo, the disk is writing 2.5M/s, which is not much if they are contiguous writes, but much more relevant if they are random writes. We do not know, however, which process is writing. What is relevant, however, is the IO column: 3 processes have the CPU waiting for I/O 99.99% of the time allocated to them, instead of actually computing. Even the iotop process itself is waiting. Plasmashell, however, is only 65% waiting. Why did you add the "-P"? Are there messages related to errors or disk problems on the logs? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-06-25 10:22, Bengt Gördén wrote:

Hi,

When I do fault isolation on my systems (usually Linux routers at work or my own DAW (digital audio workstation)) I usually start with this, as root:

watch cat /proc/interrupts

It'll give you a listing of updated interrupts every other second. Use -n for other intervals. Locate the one that gives you most interrupts and go from there. As an example my DAW had serious overload on one USB-port together with other interrupts on CPU0. I moved my mixer to another port (ending up on CPU3) and all's well after that. If you need to you can move interrupts to another cpu-core with help of smp_affinity.

Interrupts are tied to a certain core? I thought they were dynamically assigned to a non busy core. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 2018-06-25 13:17, Bengt Gördén wrote:

Den 2018-06-25 kl. 11:56, skrev Carlos E. R.:

...

Interrupts are tied to a certain core? I thought they were dynamically assigned to a non busy core.

Yes. Your right. I think I was a bit unclear. What I meant was that if you have the need to redirect one interrupt source to a certain core it can be done via smp-affinity. Normally you shouldn't need that but there are cases where it is of great importance. The two cases I referred to (router and DAW) is such cases. They are real time cases. Under heavy load in a recording (audio) situation you do not want disturbance in any way and as low latency as possible. In the case of router it's crucial if you have a production system and you don't have an out-of-band solution to access the router and the traffic is very high. We did this in three different projects about 11-13 years ago where we showed that 10Gbit/s forwarding in a Linux router is possible. There we redirected the ssh-port to CPU0 and the rest of the packets were handled by core CPU1-CPU7 so that the control plane were separated from data plane.

I see :-)

But to get back to the "watch cat /proc/interrupts". It's to see were the interrupts comes from.

Yes, it is a good idea. Long ago, my computer was running very slow one day (perhaps SuSE 7.x). The process "init" was very, very busy. Single core CPU. I don't remember how I found out, but the modem was sending a flurry of interrupts over the serial port. I power cycled the modem and problem solved. :-) It never happened again. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

Op vrijdag 22 juni 2018 16:44:01 CEST schreef Axel Braun:

Am Freitag, 22. Juni 2018, 14:25:52 CEST schrieb Patrick Shanahan:

...

* Axel Braun [06-22-18 07:53]:

...

Hi again,

I still face an issue on the Desktop I have converted from Leap 42.3 to 15. Desktop (KDE) is partly unresponsive for 2 Minutes, full load on both CPU cores, most likely due to disk-activities (baloo....). Not even CRTL-ESC is working during this time.

Is there any tweak to make it more responsive? - Different kind of Kernel or Kernel scheduler? Currently running the default kernel. - any idea to reduce the priority of baloo in order to reduce the disk activities?

Dual Core Intel G4400@3.3 GHz, 8G RAM, MSI H110M PRO-D Motherboard Any additional information needed?

have you tried top or htop to see what process(s) is stalling your system rather than "most likely" as you leave us shooting in the dark.

you are right, top gives a better overview than KDE process monitor

At the top of the list, esp, when there is no response from the desktop, is plasmashell and kwin_X11.

Graphics is an Intel i915 - is this maybe related? southpole: # lspci -s 00:02.0 -v 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7996 Flags: bus master, fast devsel, latency 0, IRQ 122 Memory at de000000 (64-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Kernel driver in use: i915 Kernel modules: i915

Best, Axel What would actually be interesting to see is the top output whilst the desktop being frozen. I do suscpect baloo, and suggest you have it rebuild it's database. I've seen this a couple of times in the forums, where the conclusion was that the baloo database was corrupted, since after it rebuilt it's database the issue of freezing was gone. So, move it ( and all baloo's settings ) whilst being logged out, log back in and see what happens.

-- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org