=== henrix_ is now known as henrix
apwrtg, i am pushing bits for the i386 cloud tools, so expect unreleased changes in -meta for you next upload09:53
rtgapw, ack09:53
=== ming is now known as Guest82927
shadeslayerjsalisbury: apw remember our discussion from http://irclogs.ubuntu.com/2014/06/10/%23ubuntu-kernel.html#t16:5112:56
shadeslayerjsalisbury: apw we were wondering if we can change to CFQ in 14.04 as well12:56
ubot5Ubuntu bug 1378789 in kubuntu-settings (Ubuntu Trusty) "[SRU] Set the default IO scheduler to CFQ in Kubuntu Trusty" [Undecided,New]12:56
shadeslayerjsalisbury: apw would be awesome if you could comment there about your thoughts12:56
apwthere is little chance of us changing default IO scheduler in a released OS12:57
shadeslayerapw: this would be for Kubuntu12:58
apwshadeslayer, iirc you are changing it via udev rules right ?12:58
shadeslayerand more specifically, it'd be a udev rule, which is loaded post boot ( I think )12:58
shadeslayerapw: yes12:58
apwok, so what i am i commenting on :)12:58
shadeslayerapw: ScottK wanted to know if this was alright with the kernel team12:59
shadeslayerapw: let me get him in here :p12:59
shadeslayerScottK: so if I understood it correctly, you just wanted to ask the kernel team if this was alright for 14.04?13:00
ScottKI'd like to get an appreciation of the potential risks associated with the change to assess if it's SRU worthy.13:00
shadeslayerapw: fwiw we've already changed in 14.10, so far no issues for the last month that we know of13:00
ScottKRight, but the level of risk we generally accept in the development series is different than for an SRU.13:01
shadeslayerScottK: right, just bringing apw up to speed with the current situation in Kubuntu :)13:02
* apw concurs on that13:02
apwwe moved away from cfq because it was creating performance instabilities on interactive workloads13:02
apwbut you are relying on a cfq specific feature, so you are somewhat hosed13:02
cking..I guess what ever choice is made there is always a particular usecase that can show up performance issues with specific usecases13:03
ScottKapw: How long ago did we switch from cfq?13:04
* shadeslayer thinks that we're circling back to the original conclusion of : Benchmarks are outdated13:04
* ScottK wonders if it might be better now.13:04
apwScottK, it was somewhere arond precise i think, a long time ago13:05
shadeslayerScottK: something that was bought up in the original discussion, no one has up-to-date benchmarks ( this was 3 months ago )13:05
* cking has a peek at the latest data to remind himself of the current position13:05
apwScottK, yeah it might be better, i cann't recall if we have done anything since13:05
apwcking, is stats master13:05
shadeslayeralso, benchmarking depends highly on the kind of workload13:05
* ScottK starts to imagine a trip to the tech board on this one (which is not terribly unusual for "we think we should SRU, but it has risks."13:07
ckingshadeslayer, exactly, and it is kind of tricky to select a set of tests that cover every application's useage patterns. it's like 10 pin bowling, you kind of aim for the best all round choice, but you know there may be some pins on the side that you may miss13:07
shadeslayerScottK: *groan*13:07
shadeslayercking: right13:07
ScottKshadeslayer: You weren't around when we released an X update for Dapper that broke X ~everywhere.13:08
ScottKIt kind of sucked.  We have the rules in place for a reason.13:08
Riddellthis is only changing a setting back to the upstream default is it not?13:09
ScottKshadeslayer: My alternate thought was wait for a month after 12.10 is released to see if issues come up.13:09
ckingoops, I mean: http://kernel.ubuntu.com/~cking/fs-tests/sept/test/kernel-trends/13:09
apacheloggerRiddell: yes13:09
shadeslayerScottK: right, but IO Schedulers are supposed to be drop in replacement ...13:09
shadeslayerunless there are very intrusive patches13:09
shadeslayerthat screw up things 13:09
shadeslayerwhich I would imagin there are not13:09
shadeslayerbut then, not a kernel dev13:09
ScottKIf IO schedulers are drop in for each other, then logically there's no need to change.13:09
ScottKNot the flaw in that logic.13:10
ckingyou should be OK to drop in the change to cfq, but like all things, there may be issues with that which cause other performance drops compared to deadline13:10
apacheloggerthat logic is so flawed it hurts13:10
ScottKActually the logic is correct, it's the premise that's broken.13:10
apacheloggerdeadline does not implement a priority system because by design deadline deadlines, regardless of the priority13:10
apacheloggerit's kinda the point of deadline13:10
ScottKRight.  By definition these things are not just drop in replacements for each other.13:11
apacheloggerof course addressing requests as they deadline instead of as they make sense hdd-sector-wise or as they are prioritized as it were is kind of bad in spinning media world13:11
Riddellit seems fairly obvious that the major io user in kubuntu is baloo, baloo just needs upstream defaults, it does seem like a bug that ubuntu changes those and the whole kde desktop suffers13:13
apacheloggerScottK: they are drop in replacements in that they both will schedule your IO and your IO is going to happen at some point $soon, the meaning of soon is divergent13:15
ScottKRight.  It would have been much easier to address pre-release.13:15
apacheloggerwhich is also why one shouldn't make assumptions about the soonyness of things13:15
=== sr105|aw` is now known as sr105
ckingit would also be interesting to see what kind of i/o patterns baloo is doing as well 13:17
ScottKIs there something like bootchart for capturing data like that?13:18
ckingblktrace perhaps, http://smackerelofopinion.blogspot.co.uk/2009/10/block-io-layer-tracing-using-blktrace.html13:19
Riddellwe know baloo needs cfq and suffers with deadline, vishesh has done lots of tests of that13:19
ckingRiddell,  any references on that analysis? 13:20
ckingScottK, http://smackerelofopinion.blogspot.co.uk/2009/10/blktrace-baded-tools-seekwatcher.html13:21
shadeslayerbtw, I think that argument was made primarily because Baloo uses ioniceness13:21
shadeslayerwhich was provided only by CFQ13:21
apacheloggerwe know baloo won't suck with CFQ because CFQ takes ioniceness into account ^^13:21
ckingah, so it's kinda niche i/o tuning13:21
shadeslayerso baloo itself doesn't suffer performance degradation when using deadline, other apps on the desktop do13:22
apacheloggerwell, technically everything suffers13:23
apacheloggeras the problem is that since baloo does loads of read requests it will constantly have requests hitting the deadline once it reached the upper ceiling of the HDD's capabilities13:23
apacheloggerafter that point deadline will basically be performing in the worst case scenario where it constantly addresses deadlined requests + one batch of queued requests13:24
apacheloggerand that in turn causes pointless HDD seeking as it does no longer access things in a way that makes sense sector-wise, so more stuff is going to deadline and the entire system is slowing down13:25
ckingwith this in mind, it's worth revisiting this for U+1 for sure13:33
* cking wonders what baloo did before ioniceness was added to the kernel13:36
apacheloggercking: didn't exist then I think13:37
apacheloggerand the previous thing was broken by design and implementation, so most people didn't actually use it ^^13:37
ckingI think that feature landed in 2.6.26 ish13:37
apacheloggeryeah, baloo only got invented like 2 years ago13:38
ckingah, it's interesting that one is now kind of locked into just using cfq because of the behaviour required by baloo. I wonder if that is totally acceptable13:39
apwwhether its totally reasonable, indeed13:46
apacheloggerit is somewhat peculiar, but I for one lack the knowledge to argue any better approach to the problem13:47
* apw idly wonders how the other indexers we use on the desktop work without hammering the machine to death13:48
* ScottK thinks "not very well"13:53
=== amitk_ is now known as amitk
hallynapw: someone reported that in 3.15 overlayfs switched from 'upperdir=' to 'workdir='.  that doesn't seem to e the case in utopic though.  d oyou know anything about it?14:09
hallynin particular an easy way for lxc to tell which it needs to use?  (or whether it'll be reverted upstream)14:09
hallyni don't see how chnaging that could possible meet the 'don't mess with userspace' mandate14:09
apwhallyn, well its outside the kernel so ... it doesn't get held to any kind of compatibility standard14:10
hallynoh.  right14:10
hallynit'd be nice if either upperdir was always supported or there was a clean way to tell which to use from a script though :)14:10
apwhallyn, we haven't switched to the latest version because it has another incompatible change, which i need to think about before we could14:10
apwhallyn, indeed .. sigh ... 14:11
hallynfor now i'll just say "tough noogies" :)14:11
* apw will look into it14:11
apwhallyn, that doc says you need a new option workdir which would need to point to a private space, lost+found stylee for use with the new atomic rename swap stuff they are using14:12
hallynoh so they still take upperdir?14:13
apwhallyn, that is my reading of it yes14:19
apw mount -t overlayfs overlayfs -olowerdir=/lower,upperdir=/upper,\14:19
apwworkdir=/work /merged14:19
apwhas all three in it14:19
hallynapw: ok, thanks14:26
* hallyn checks whether tha tis optional14:26
hallyndoesn't look so14:26
apwhallyn, well we won't be taking that version for a bit yet, don't know if it is for us you are worrying of course14:27
hallynapw: well that too, but also whoever reported it, who presumably has a bug as a result :)14:28
hallyni'll ask neal about it14:28
apwyou might be able to always supply it ...14:28
apweven though it is ignored14:28
apwso attempt ot mount with, fail and attempt to mount without, and hope14:32
apwi know, very kernel14:33
hallynthx apw14:33
* apw feels dirty14:34
hallyni'm having a very scatterbrained week14:34
davmor2apw: stop plating on windows then14:35
slangasekcking: hi, so I replied to your mail because I didn't understand your response17:32
slangasekmaybe we can discuss here17:32
slangasekapw: "other indexers on the desktop" - don't you remember?  they were all horrible and we either got rid of them, or stopped noticing the impact at the same time we all switched to SSDs17:36
slangasekok, caught up on the discussion here wrt baloo17:37
slangasekthat's some useful context17:37
ckingslangasek, sorry, I was having some food17:37
cking CFQ is the only one that handles ioniceness17:37
slangasekcking, apw: what I would like to understand is, do we actually have benchmarks measuring cfq vs. deadline for rotational vs. ssd?  Because it seems there's quite a relevant difference in behavior; are we sure deadline is actually the right default on rotational?17:37
slangasek(i.e., is there a reason that we shouldn't consider the udev rule that kubuntu-settings has implemented to be correct across the board?)17:38
slangasekmaybe we still wouldn't want to SRU such a change into the kernel even if we thought it was correct17:38
ckingslangasek, I need to look up my historical data on this, which may take me a while to do17:38
slangasekbut I'd like to have a clearer understanding of what we do think is correct17:38
slangasekcking: ok; no hurry for my part, but I'd appreciate having that info17:38
ckingslangasek, all choices are correct and also wrong depending on the use case :-/17:39
apwi'd have to defer to cking's numbers, i know we thought not previously17:39
=== bjf[afk] is now known as bjf

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!