You are not logged in.

#1 2018-07-27 21:41:11

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

[SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

There are two programs that make some trouble here. The 1st is 'extra/meld' and the 2nd is 'aur/vapoursynth-editor'. Both create some files that are constantly accessed (write) when moving their main windows or some sliders. For 'meld' its '~/.config/dconf' and for vapoursynth-editor (vsedit) its '~/.config/vsedit.config.lock'. If you have a mechanical HDD you can clearly hear it (max head seeking). Otherwise you can take 'iotop' or 'strace'. Data throughput is not very high regarding 'iotop' (like 150KB/s) but I/O queuing(?) is 100% (jbd2/sda2 = journaling). It can be workaround by moving/linking the files to tmpfs (for vsedit it must be done after the program has been started).
The HDD hammering is in sync with the mouse. You can actually make music with it (low latency). There is no delay at all. And that's the question. Why is the HDD write cache not kicking in here? Shouldn't it "absorb" such activities by design? Or are the applications explicitly disable the write cache here?

My home folder is mounted with this options in fstab:
rw,relatime,data=writeback,commit=30

Last edited by Maniaxx (2018-11-22 01:51:52)


sys2064

Offline

#2 2018-07-27 22:44:42

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

For meld try in a separate terminal  `dconf watch /`

Offline

#3 2018-07-28 07:33:51

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

One can never add too many fsync() calls into ones code…

hdparm -W /dev/sd<diskwhereyourhomepartitionisnotthepartition>

Offline

#4 2018-07-28 18:45:28

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

loqs wrote:

For meld try in a separate terminal  `dconf watch /`

I get many of this when scaling the window:

/org/gnome/meld/window-state/width
  1454

/org/gnome/meld/window-state/height
  881
seth wrote:

One can never add too many fsync() calls into ones code…

hdparm -W /dev/sd<diskwhereyourhomepartitionisnotthepartition>

Its already on.
Looks like both apps save window metrics in realtime.

Can anyone reproduce this behavior on VapourSynth Editor with 'iotop' (i'm not sure anymore if 'meld' can be seen with that as well)?


sys2064

Offline

#5 2018-07-28 21:07:51

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

If it successfully updates the dconf, the iotop is no surprise.
Sidestepping the drive cache is not  possible and even flushing it should require root permissions, but if it's sufficiently filled and the entire config is re-written (at pretty high frequency), you maybe constantly run out of cache.

The applications should of course be compressing such events as trigger to IO, but if it does not explicity sync to disk, the writeback option might cause a bypass of the OS cache.

Offline

#6 2018-07-28 23:22:36

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

@seth I would expect the file would be required to be opened with O_DIRECT | O_DSYNC or O_DIRECT | O_SYNC in order for the write to pass through all the kernel layers
without being held any cache that would allow newer updates to replace the older ones.

Offline

#7 2018-07-28 23:48:40

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

seth wrote:

If it successfully updates the dconf, the iotop is no surprise.

But it updates it 100 times per second or something like that. Exactly like vsedit (per-pixel movement update).

I've enabled data=ordered again but it doesn't change anything. I have two sata controllers. I will switch the ports tomorrow.

Direct sync is my assumption as well. The dev of vsedit says the *.lock file behavior is related to "underlying implementation" but the per-pixel movement update probably is not. He will look into it.

Last edited by Maniaxx (2018-07-28 23:51:19)


sys2064

Offline

#8 2018-07-29 00:11:25

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

In the case of vapoursynth-editor you might want to trace how many times http://doc.qt.io/qt-5/qsettings.html#sync is called.
Edit:
If you comment out all uses of sync in  common-src/settings/settings_manager_core.cpp and common-src/settings/settings_manager_core.cpp and rebuild does that resolve the issue for vapoursynth-editor?

Last edited by loqs (2018-07-29 00:32:01)

Offline

#9 2018-07-29 16:53:15

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

loqs wrote:

If you comment out all uses of sync in  common-src/settings/settings_manager_core.cpp and common-src/settings/settings_manager_core.cpp and rebuild does that resolve the issue for vapoursynth-editor?

Doesn't affect it (and yes, i've noticed your typo).

strace snippet (filter: vsedit.config).
The strace file has been recorded for 5.5 seconds (4.3MB unfiltered, 625KB filtered). There are 710 statx(), 325 access(), 94 openat(), 92 linkat(), 46 rename() and 46 unlink() calls.
There seems to be an impressive amount of statx() calls.

openat(AT_FDCWD, "/home/user/.config/vsedit.config", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 24
openat(AT_FDCWD, "/home/user/.config/vsedit.config.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 24
access("/home/user/.config/vsedit.config", F_OK) = 0
statx(AT_FDCWD, "/home/user/.config/vsedit.config", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=1000, stx_gid=1000, stx_mode=S_IFREG|0644, stx_ino=8411546, stx_size=4876, stx_blocks=16, stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED, stx_atime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_btime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_ctime={tv_sec=1532881245, tv_nsec=514106964} /* 2018-07-29T18:20:45.514106964+0200 */, stx_mtime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=8, stx_dev_minor=6}) = 0
access("/home/user/.config/vsedit.config", F_OK) = 0
access("/home/user/.config/vsedit.config", W_OK) = 0
statx(AT_FDCWD, "/home/user/.config/vsedit.config", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=1000, stx_gid=1000, stx_mode=S_IFREG|0644, stx_ino=8411546, stx_size=4876, stx_blocks=16, stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED, stx_atime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_btime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_ctime={tv_sec=1532881245, tv_nsec=514106964} /* 2018-07-29T18:20:45.514106964+0200 */, stx_mtime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=8, stx_dev_minor=6}) = 0
statx(AT_FDCWD, "/home/user/.config/vsedit.config", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_ALL, stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=1000, stx_gid=1000, stx_mode=S_IFREG|0644, stx_ino=8411546, stx_size=4876, stx_blocks=16, stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED, stx_atime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_btime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_ctime={tv_sec=1532881245, tv_nsec=514106964} /* 2018-07-29T18:20:45.514106964+0200 */, stx_mtime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=8, stx_dev_minor=6}) = 0
statx(AT_FDCWD, "/home/user/.config/vsedit.config", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=1000, stx_gid=1000, stx_mode=S_IFREG|0644, stx_ino=8411546, stx_size=4876, stx_blocks=16, stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED, stx_atime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_btime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_ctime={tv_sec=1532881245, tv_nsec=514106964} /* 2018-07-29T18:20:45.514106964+0200 */, stx_mtime={tv_sec=1532881245, tv_nsec=480773115} /* 2018-07-29T18:20:45.480773115+0200 */, stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=8, stx_dev_minor=6}) = 0
access("/home/user/.config/vsedit.config", R_OK) = 0
access("/home/user/.config/vsedit.config", W_OK) = 0
access("/home/user/.config/vsedit.config", X_OK) = -1 EACCES (Keine Berechtigung)
linkat(AT_FDCWD, "/proc/self/fd/25", AT_FDCWD, "/home/user/.config/vsedit.config", AT_SYMLINK_FOLLOW) = -1 EEXIST (Die Datei existiert bereits)
linkat(AT_FDCWD, "/proc/self/fd/25", AT_FDCWD, "/home/user/.config/vsedit.config.agVOgf", AT_SYMLINK_FOLLOW) = 0
rename("/home/user/.config/vsedit.config.agVOgf", "/home/user/.config/vsedit.config") = 0
statx(AT_FDCWD, "/home/user/.config/vsedit.config", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=1000, stx_gid=1000, stx_mode=S_IFREG|0644, stx_ino=8411561, stx_size=4876, stx_blocks=16, stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED, stx_atime={tv_sec=1532881245, tv_nsec=547440813} /* 2018-07-29T18:20:45.547440813+0200 */, stx_btime={tv_sec=1532881245, tv_nsec=547440813} /* 2018-07-29T18:20:45.547440813+0200 */, stx_ctime={tv_sec=1532881245, tv_nsec=580774663} /* 2018-07-29T18:20:45.580774663+0200 */, stx_mtime={tv_sec=1532881245, tv_nsec=547440813} /* 2018-07-29T18:20:45.547440813+0200 */, stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=8, stx_dev_minor=6}) = 0
unlink("/home/user/.config/vsedit.config.lock") = 0
statx(AT_FDCWD, "/home/user/.config/vsedit.config", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_blksize=4096, stx_attributes=0, stx_nlink=1, stx_uid=1000, stx_gid=1000, stx_mode=S_IFREG|0644, stx_ino=8411561, stx_size=4876, stx_blocks=16, stx_attributes_mask=STATX_ATTR_COMPRESSED|STATX_ATTR_IMMUTABLE|STATX_ATTR_APPEND|STATX_ATTR_NODUMP|STATX_ATTR_ENCRYPTED, stx_atime={tv_sec=1532881245, tv_nsec=547440813} /* 2018-07-29T18:20:45.547440813+0200 */, stx_btime={tv_sec=1532881245, tv_nsec=547440813} /* 2018-07-29T18:20:45.547440813+0200 */, stx_ctime={tv_sec=1532881245, tv_nsec=580774663} /* 2018-07-29T18:20:45.580774663+0200 */, stx_mtime={tv_sec=1532881245, tv_nsec=547440813} /* 2018-07-29T18:20:45.547440813+0200 */, stx_rdev_major=0, stx_rdev_minor=0, stx_dev_major=8, stx_dev_minor=6}) = 0
access("/home/user/.config/vsedit.config", F_OK) = 0

Last edited by Maniaxx (2018-07-29 16:58:27)


sys2064

Offline

#10 2018-07-29 17:16:54

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

Maniaxx wrote:

Doesn't affect it (and yes, i've noticed your typo).

Sorry I can not spot my typo.
Edit:

	if(!isMaximized())
		m_pSettingsManager->setMainWindowGeometry(saveGeometry());

If you comment out that block from moveEvent and resizeEvent of main_window.cpp does that reduce the IO for main window movement?

Looking at the strace there is no read or write calls.

Last edited by loqs (2018-07-29 17:36:30)

Offline

#11 2018-07-29 17:45:06

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

While remarkably inefficient, the multiple stats on the same file won't cause additional disk access and the COW writing is actually ok (because you don't want to risk borking the config)

The problem is apparently this crap in vsedit/src/main_window.cpp

void MainWindow::moveEvent(QMoveEvent * a_pEvent)
{
	QMainWindow::moveEvent(a_pEvent);
	QApplication::processEvents();
	if(!isMaximized())
		m_pSettingsManager->setMainWindowGeometry(saveGeometry());
}


void MainWindow::resizeEvent(QResizeEvent * a_pEvent)
{
	QMainWindow::resizeEvent(a_pEvent);
	QApplication::processEvents();
	if(!isMaximized())
		m_pSettingsManager->setMainWindowGeometry(saveGeometry());
}

which is just nuts, add a static QTimer (maybe a 5s timeout or so), bind it to a lambda slot to write the config and restart the timer w/ every move event.

Or even better, if the settings do not *need* to be read from outside (if some other process requires accurate geometry: hello dbus), just store the geometry in the ::closeEvent right above the geometry events.
Be aware that the code also writes settings on un/maximization and while not as bad, that's still nuts.

The only "justification" for this behavior is if you expect "unclean exits", ie. the process crashes a lot…

Edit: ninja'd by loqs. Shame on you ;-)

Last edited by seth (2018-07-29 17:45:49)

Offline

#12 2018-07-29 19:29:16

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

@seth on meld possibly something in https://github.com/GNOME/meld/blob/ab7d … ate.py#L39 ?

Offline

#13 2018-07-29 19:31:02

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

loqs wrote:
	if(!isMaximized())
		m_pSettingsManager->setMainWindowGeometry(saveGeometry());

Works, thanks! smile

loqs wrote:

I can not spot my typo.

You were pointing to the same file twice (settings_manager_core.cpp). The other one was 'settings_manager.cpp' or something.

loqs wrote:

Looking at the strace there is no read or write calls.

Yes, my fault. The snippet only shows entries with the filename.

Last edited by Maniaxx (2018-07-29 19:32:23)


sys2064

Offline

#14 2018-07-29 20:30:11

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

I'm gonna guess bind the settings to "on_unrealize(widget)" but I never used pygtk - it might just terminate the process w/o proper cleanup, but when actually closing the window, there's probably still an "on_unmap_event(widget, event)"
Also the on_window_state_event "event" should actually carry a Gdk.EventWindowState which provides the new state, the changed attribute and the state flags include "WITHDRAWN" - which is technically not "unmapped" on an X11 layer, but might suffice (to keep the code simpler)

Offline

#15 2018-07-29 20:45:51

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

I went for a simpler test

        bind_flags = (
            Gio.SettingsBindFlags.GET |
            Gio.SettingsBindFlags.GET_NO_CHANGES

The settings are read once and never updated not the desired result but meld no longer updates dconf.

Offline

#16 2018-07-29 20:55:23

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

self.settings.get_int/self.settings.get_boolean, but if the settings are never written, loading them makes no sense at all either.

Offline

#17 2018-07-29 22:49:17

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

https://wiki.gnome.org/HowDoI/SaveWindowState seems to explain what should be done but I have no idea how to implement it (the none bind implementation before additional tips)
Edit:
meld seems to be following the reference implementation using the binding method.

Last edited by loqs (2018-07-29 23:59:18)

Offline

#18 2018-07-30 05:54:37

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

One thing that's odd is that the code suggests settings updates on size and state changes (what's stupid enough), but OP suggests IO on "moving their main windows or some sliders" so one question may be why the window is resized when being moved (or possibly there're maximization unrelated state changes, like focus, and the "GET_NO_CHANGES" flag does not actually prevent idempotent writes…)

Offline

#19 2018-07-30 10:27:04

Maniaxx
Member
Registered: 2014-05-14
Posts: 732

Re: [SLVD]High I/O trouble - HDD write cache doesn't kick in on some files

I've re-checked that and indeed moving is ok in meld (i was wrong in 1st post). Scaling and moving sliders are affected there.


sys2064

Offline

Board footer

Powered by FluxBB