| YokoZar | Or is it just like package build-deps and that they must all be satisfied within-arch | 00:00 |
|---|---|---|
| === freeflying_away is now known as freeflying | ||
| mwhudson | i have a php5 build that's exploding because mysql can't create a database to run tests in or something | 00:44 |
| mwhudson | does this ring any bells with anyone? | 00:44 |
| sarnold | mwhudson: there's some funny magic in the mysql upstart to ensure an apparmor profile is loaded; I wonder if (a) your apparmor fails to load thus the database fails to load (b) the profile does load, but forbids the testing location? | 00:46 |
| mwhudson | sarnold: this sounds plausible | 00:46 |
| mwhudson | do the buildds have especially crippled apparmor? | 00:47 |
| mwhudson | and is there some way i can turn it off to verify? | 00:47 |
| mwhudson | well apt-get install apparmor-profiles sure complained a lot | 00:49 |
| mwhudson | yes ok | 00:52 |
| mwhudson | Sep 12 20:51:00 h9a kernel: [3212473.992787] type=1400 audit(1379033460.123:64): apparmor="DENIED" operation="mknod" parent=26437 profile="/usr/sbin/mysqld" name="/home/ubuntu/php5-5.4.9/mysql_db/h9a.lower-test" pid=26458 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 | 00:52 |
| mwhudson | sarnold: how can i tell apparmor to FOAD? | 00:52 |
| sarnold | mwhudson: good question, I've never poked at the php5 build before :/ | 00:55 |
| mwhudson | maybe i can just put my build directory in /tmp :) | 00:57 |
| rbasak | That's odd. I've had issues building php5 locally, but not seen that particular issue. Are you using sbuild, or something else? And which version? | 00:58 |
| mwhudson | rbasak: just running debuild | 00:58 |
| mwhudson | and it's php5_5.4.9-4ubuntu2.3 + a couple of patches | 00:59 |
| rbasak | mwhudson: are you using -rfakeroot? | 00:59 |
| mwhudson | ubuntu@h9a:/tmp/php5-5.4.9$ debuild | 01:00 |
| mwhudson | dpkg-buildpackage -rfakeroot -D -us -uc | 01:00 |
| mwhudson | dpkg-buildpackage: source package php5 | 01:00 |
| mwhudson | ... | 01:00 |
| mwhudson | rbasak: looks like it? | 01:00 |
| rbasak | Yeah I guess so. | 01:00 |
| rbasak | I'm a bit confused. Why does apparmor see an mknod call at all? | 01:01 |
| sarnold | hrm, this page suggests that the <name>.lower-test file write isn't serious and can be ignored http://dev.mysql.com/doc/refman/5.0/en/cannot-create.html | 01:04 |
| mwhudson | well | 01:07 |
| mwhudson | the process that produces that error then falls over in a heap and exits with code 1 | 01:07 |
| mwhudson | i make no claims as to know what's going on :) | 01:07 |
| * mwhudson is running the build in /tmp now.... | 01:08 | |
| rbasak | Do you need to run the test suite? You could disable it with nocheck. | 01:08 |
| mwhudson | well | 01:08 |
| rbasak | (assuming the packaging supports that) | 01:08 |
| mwhudson | i would _like_ to run the test suite | 01:08 |
| rbasak | :) | 01:09 |
| mwhudson | but it's not essential for this i guess | 01:09 |
| mwhudson | it appears the package does support nocheck so i'll try that next | 01:09 |
| * mwhudson goes for a walk | 01:11 | |
| === _salem is now known as salem_ | ||
| infinity | pitti: Does germanium need to learn about arm64, or will it just pick it up magically? | 02:08 |
| === freeflying is now known as freeflying_away | ||
| === salem_ is now known as _salem | ||
| === freeflying_away is now known as freeflying | ||
| slangasek | jbicha: erm, I thought CC-BY{,-SA}-2.0 were allowed in Debian... I've not heard of packages being rejected from main as a result of either of these. But in any case, the license wasn't listed in debian/copyright, which is certainly an ftp reject reason | 04:27 |
| slangasek | hmm, not actually here | 04:27 |
| === jono is now known as Guest64072 | ||
| DktrKranz | slangasek: CC-BY-*-2.0 is not allowed in Debian main | 06:35 |
| slangasek | DktrKranz: ah, ok. I always get confused about which versions were the "good" ones | 06:38 |
| DktrKranz | at the moment, CC-BY-SA-3.0 is fine | 06:39 |
| DktrKranz | (we should really complete http://ftp-master.debian.org/licenses/) | 06:41 |
| slangasek | might be useful, yes :) | 06:41 |
| dholbach | good morning | 06:45 |
| dholbach | can somebody please reject https://code.launchpad.net/~xnox/ubuntu-seeds/ubuntu-touch.remove-webapps-demo/+merge/185092? | 07:01 |
| dholbach | (based on the comment) | 07:01 |
| === smb` is now known as smb | ||
| xnox | dholbach: done. | 07:54 |
| dholbach | thanks xnox | 07:58 |
| xnox | YokoZar: at the moment we don't have cross-arch dependencies, but, if multi-arch is enabled, you can depend on a package which only present on that arch to get a similar effect. | 07:58 |
| xnox | YokoZar: see wine on amd64 for example. | 07:58 |
| === tsimpson_ is now known as tsimpson | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| === freeflying is now known as freeflying_away | ||
| YokoZar | xnox: I was asking because I wanted to add winetest to wine's amd64 package, but it depends on wine's 32 bit as well ;) | 10:11 |
| * mlankhorst pokes YokoZar | 10:42 | |
| cjwatson | mdeslaur: Mind if I merge libxcb? It fails to build in saucy because it's out of sync with xcb-proto; the new upstream fixes that. | 10:42 |
| cjwatson | mdeslaur: (this is a blocker for the arm64 bootstrap) | 10:42 |
| === doko_ is now known as doko | ||
| === MacSlow is now known as MacSlow|lunch | ||
| rbasak | kirkland: hey! Could you please see if https://code.launchpad.net/~dannf/cpu-checker/arm-cortex-a15/+merge/171667 is OK to land? I asked kees but I guess he's busy. It looks like you are in ~cpu-checker-dev too? | 10:52 |
| cjwatson | mdeslaur: It does have your security fix | 10:56 |
| brendand | rbasak, is there an armhf build of cpu-checker available yet? | 11:02 |
| rbasak | brendand: not that I'm aware of, although AIUI dannf's patch is all that is needed. I'll propose a distro patch if we can't get his patched merged upstream soon. | 11:03 |
| mdeslaur | cjwatson: not at all, go right ahead | 11:24 |
| === freeflying_away is now known as freeflying | ||
| cjwatson | mdeslaur: thanks, done | 11:27 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | cjwatson, hi | 11:37 |
| mdeslaur | dholbach: can I please push my patch piloting to monday? | 11:49 |
| dholbach | mdeslaur, sure, whenever you like it best - just move it in the calendar | 11:50 |
| dholbach | mdeslaur, the schedule I set up is more just a reminder | 11:50 |
| cjwatson | tkamppeter: yes? | 11:52 |
| === mzanetti is now known as mzanetti|lunch | ||
| tkamppeter | cjwatson, I have a problem with PackageKit, called from a Python program, /usr/bin/install-printerdriver. | 12:09 |
| tkamppeter | cjwatson, http://paste.ubuntu.com/6101343/ | 12:10 |
| cjwatson | tkamppeter: I only started learning about PackageKit a couple of months ago, and I only know as much about it as I've needed for click; this isn't a corner of it I know, I'm afraid | 12:10 |
| tkamppeter | cjwatson, who could I ask? | 12:12 |
| cjwatson | tkamppeter: I'm not sure. Sebastian Heinlein, maybe, if you can track him down | 12:12 |
| === MacSlow|lunch is now known as MacSlow | ||
| tkamppeter | cjwatson, thank you. | 12:13 |
| === _salem is now known as salem_ | ||
| mdeslaur | dholbach: cool, thanks | 12:21 |
| mdeslaur | dholbach: google calendar won't save the changes, sorry | 12:24 |
| juliank | tkamppeter: You could ask ximion for help on the PackageKit problem (if it's really related to PackageKit, and not something in aptdaemon's pkcompat stuff, but it seems to be in the PackageKit client bindings) once he's back; although I don't know when he'll be online again. | 12:31 |
| juliank | If this is also PackageKit on the server side (that is, aptdaemon's pkcompat is not involved) you can also ask in #PackageKit, although no Debian or Ubuntu people seem to be there at the moment except for me. | 12:32 |
| tkamppeter | juliank, I have installed the Saucy package of system-config-printer on Raring now and there it works, so it seems to be a PackageKit or aptdaemon regression in Saucy. | 12:40 |
| tkamppeter | juliank, thanks, if I do not find them I will report a bug. | 12:40 |
| dholbach | mdeslaur, no worries | 12:44 |
| pitti | Good morning | 12:49 |
| pitti | infinity: nope, no magic; I'll tell it about it | 12:49 |
| pitti | infinity: hm, I added arm64 for saucy and re-pulled the last 7 days of ddebs, but it seems it didn't pick up a single arm64 binary; did we actually have any yet? | 13:03 |
| cjwatson | pitti: We have a small handful | 13:03 |
| cjwatson | Still working on the bootstrap | 13:04 |
| pitti | hmm, /me looks closer | 13:04 |
| pitti | oha: The requested URL /~buildd/ddebs/ was not found on this server. | 13:04 |
| pitti | that's http://birch.buildd/~buildd/ddebs/ | 13:05 |
| cjwatson | pitti: Note that they've been going into saucy (release) rather than saucy-proposed, if that makes a difference | 13:05 |
| pitti | infinity: so it seems these buildds aren't apache-ified yet? | 13:05 |
| cjwatson | That's an error message from Apache, surely? | 13:05 |
| pitti | yes, sorry; I meant the buildd hack hasn't been applied there? | 13:05 |
| pitti | neither on magic nor kijo01 | 13:06 |
| === mzanetti|lunch is now known as mzanetti | ||
| GuidoPallemans | Hey guys, I have a problem installing my own click package on my computer, should I be worried? | 13:24 |
| GuidoPallemans | in the ubuntu software center i get an error <filename>_1.0_all.clickâ could not be opened. | 13:24 |
| cjwatson | GuidoPallemans: Installing click packages on the desktop is kind of possible with some hackery, but it's not supported yet and certainly not via Software Center. | 13:31 |
| cjwatson | GuidoPallemans: For 13.10 they're just for touch devices. | 13:31 |
| GuidoPallemans | oh ok. | 13:32 |
| GuidoPallemans | thanks! | 13:32 |
| GuidoPallemans | but how can I test them then? | 13:32 |
| cjwatson | GuidoPallemans: You'll need a touch device ... | 13:33 |
| GuidoPallemans | dang | 13:33 |
| cjwatson | (There's work in progress on an emulator) | 13:36 |
| OvenWerks | cjwatson: I asked aboout dssi-vst on our ML and I am told falktx has talken it over as maitainer and will be reintroducing it to debian. Not sure of time frame. His builds both 32/64bit. | 13:51 |
| diwic | slangasek, do you have time to explain how to fix a multi-arch related bug to me? | 13:52 |
| OvenWerks | cjwatson: (the building in 64bit doesn't stop it from needing wine) | 13:53 |
| cjwatson | OvenWerks: OK, thanks | 13:55 |
| === kentb is now known as kentb-afk | ||
| GSport | everything i say is copyrighted | 14:34 |
| infinity | pitti: I see ddebs directories on all but kijo01 (that host isn't being used). | 14:50 |
| infinity | Oh, maybe mod_userdir isn't enabled. | 14:51 |
| infinity | pitti: Okay, fixed. Should be ddebs to fetch now. | 14:52 |
| === kentb-afk is now known as kentb | ||
| SuperLag | Thank you guys for your work on the distro. It rocks. You guys rock. :) | 15:18 |
| SuperLag | Has there been any official decision made on whether Ubuntu is going to move to a rolling release model, or not? or is that still up in the air? | 15:18 |
| === sam113101 is now known as sam113101_afk | ||
| stgraber | SuperLag: there has been an official decision that it wouldn't (at least for now). Though a few changes were done to reduce the support length of non-LTS releases and make it easier for people to track the development release. | 15:22 |
| === freeflying is now known as freeflying_away | ||
| stgraber | SuperLag: http://fridge.ubuntu.com/2013/03/19/changes-in-ubuntu-releases-decided-by-the-ubuntu-technical-board/ for the summary I wrote of the relevant Technical Board meeting | 15:25 |
| stgraber | SuperLag: https://lists.ubuntu.com/archives/technical-board/2013-March/thread.html has some more details of the discussions too | 15:25 |
| jbicha | why does ibus-xkbc's excuses say 'unsatisfiable Depends: python:any (>= 2.7.1-0ubuntu2)' | 15:29 |
| cjwatson | jbicha: Because proposed-migration doesn't understand :any yet - I have most of a patch to fix this and will land it before saucy | 15:30 |
| cjwatson | Did it towards the end of Debconf and then got distracted by vacation and forgot about it :) | 15:30 |
| jbicha | cjwatson: ok, thanks | 15:31 |
| slangasek | cjwatson: oh, did I jump the gun by getting dh-python :any-fied? :) | 15:32 |
| cjwatson | slangasek: I may have forgotten to mention this, largely because I'd forgotten that I hadn't finished this ... | 15:33 |
| cjwatson | slangasek: Will get it done early next week, my head is full of the cold right now | 15:33 |
| slangasek | cjwatson: ok. note that this means an awful lot of packages that depend on python are going to be coming through with python:any deps; I probably should've done a proper FFe request for this change... | 15:34 |
| slangasek | cjwatson: do you think I should back it out until you have a chance to work on p-m? | 15:35 |
| cjwatson | slangasek: Nah, I have most of it done and this gives me an excellent test case | 15:35 |
| cjwatson | It's just that I didn't feel like merging http://paste.ubuntu.com/6102117/ without testing its behaviour rather closely | 15:36 |
| cjwatson | (Also the patch is unfinished, as you'll see from the mismatched parens in lib/dpkg.c) | 15:37 |
| ev | pitti: rickspencer3 is seeing apport consume 100% CPU on his phone. Perhaps in this new world of mobile devices we should use a cgroup to minimise the CPU time it can use? | 15:39 |
| rickspencer3 | arg .... | 15:39 |
| ev | on second thought this is probably better handled with nice | 15:39 |
| rickspencer3 | ev additionally, the update did not apply or something | 15:39 |
| ev | rickspencer3: *nods* | 15:39 |
| rickspencer3 | let me reboot and try again | 15:39 |
| === sam113101_afk is now known as sam113101 | ||
| slangasek | ev: nice vs. cgroups, depends on the goal... if it's, say, the shell that's dead, you want apport to be greedy with the CPU because the whole thing is dead in the water until it finishes anyway, and apport won't actually be competing with other processes for resources, so a nice level is probably most logical there | 15:42 |
| slangasek | but in some cases it'll still be using 100% CPU because it *should* | 15:42 |
| ev | slangasek: yes, that was my thinking. I didn't want to restrict apport when it's not competing with anything else | 15:42 |
| * slangasek nods | 15:43 | |
| slangasek | rickspencer3: did you get to see what apport was chewing on before you rebooted? | 15:43 |
| rickspencer3 | slangasek, no, sorry | 15:43 |
| rickspencer3 | I assumed it was related to failing to download the update | 15:43 |
| rickspencer3 | arg | 15:44 |
| slangasek | rickspencer3: it was probably processing the core file for whatever crashed... so rebooting before it's done means we get no crash report from it | 15:44 |
| rickspencer3 | slangasek, sorry | 15:44 |
| rickspencer3 | slangasek, I did wait until it was not showing up in top | 15:44 |
| rickspencer3 | so I think it finished | 15:44 |
| slangasek | rickspencer3: ah, yeah, probably then | 15:44 |
| rickspencer3 | I just didn't look at what it was | 15:44 |
| slangasek | in that case whoopsie should take it from there :) | 15:44 |
| rickspencer3 | slangasek, that's what I expect, yes | 15:45 |
| ev | slangasek: while we're on the subject, lool pointed out that we probably want to handle resumable uploads for error reports on touch | 15:45 |
| ev | eventually | 15:46 |
| slangasek | ev: resumable, not just retries? | 15:46 |
| ev | yes, we already retry | 15:47 |
| ev | "an awful scenario would be that I'm on shitty internet, this large crash file never gets uploaded, but the crash happens from time to time and we never know about it and it keeps eating bandwidth on people's systems" | 15:48 |
| SuperLag | cjwatson: whiskey. Drink some. It'll burn out all those cold germs. :) | 15:49 |
| SuperLag | stgraber: thank you for the info | 15:49 |
| slangasek | ev: yeah, that's a good point. is this captured in a blueprint / bug report so we don't forget? | 15:51 |
| * mdeslaur needs some cold germs too | 15:51 | |
| ev | slangasek: on it | 15:52 |
| hallyn_ | mdeslaur: you can drink the whiskey without first getting the cold germs | 15:59 |
| mdeslaur | hallyn_: can I still claim it's medicinal? | 16:00 |
| SuperLag | haha | 16:02 |
| hallyn_ | mdeslaur: yeah, just say you drank some LA well water, I hear it has some brain fungus | 16:03 |
| mdeslaur | hehe | 16:03 |
| ev | slangasek: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1308-touch-error-reporting | 16:13 |
| pitti | infinity: confirmed, w3m works now; re-fetching | 16:14 |
| pitti | ev, rickspencer3: like, 100% forever, or just while it actually is writing the file and processing the core dump? | 16:15 |
| rickspencer3 | pitti, it seemed like it was just working normally | 16:15 |
| rickspencer3 | except that it pegged my CPU while it was doing it's thing | 16:15 |
| pitti | in general it's better to let a process run at 100% in x seconds than at 50% in 2x seconds (power-wise) | 16:15 |
| pitti | of course it should be niced so that it does'nt slow down foreground apps | 16:16 |
| pitti | rickspencer3: yeah, kind of unavoidable I'm afraid; core dumps are big, we have to compress them; we can think about using less aggressive compression maybe, but it's already only using gzip | 16:16 |
| pitti | thomi, didrocks: forgot to set a commit message before the tests ran in https://code.launchpad.net/~pitti/autopilot/bamf-dep/+merge/185497; I did that now, do we need to re-run the tests, or will the PS Jenkins bot pick up that I added it now and approve? | 16:25 |
| thomi | pitti: it gets picked up | 16:26 |
| pitti | cheers | 16:26 |
| pitti | infinity: look, arm64 ddebs! | 16:27 |
| pitti | infinity: no indexes yet, but they'll be built later in the day | 16:27 |
| infinity | pitti: Shiny. Indexes aren't critical, it's not like we have enough packages to retrace. Just wanted to make sure we didn't lose any ddebs before cleaning crons kick in. | 16:28 |
| pitti | actually, they are: | 16:28 |
| pitti | http://ddebs.ubuntu.com/dists/saucy/main/binary-arm64/Packageshttp://ddebs.ubuntu.com/dists/saucy/main/binary-arm64/Packages | 16:28 |
| * pitti draws a +5 pasting skills card | 16:28 | |
| infinity | pitti: William and I need to put our heads together and figure out a way to gina all your ddebs into the librarian some time. It'll offend me if arm64 is 99% complete in soyuz, and has 1% of its ddebs in the legacy archive. :P | 16:29 |
| didrocks | pitti: the build test ran as expected | 16:34 |
| didrocks | pitti: so, once someone set to approved, everything's will be fine, not having a commit message isn't an issue before you set to approve | 16:34 |
| pitti | didrocks: d'accord, merci | 16:35 |
| didrocks | pitti: mais de rien! | 16:36 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| slangasek | smb: good news! I still can't reproduce the bug in a VM, but I can reproduce it on my laptop ;) | 18:36 |
| cjohnston | pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1225113/comments/2 | 18:54 |
| ubottu | Launchpad bug 1225113 in apport (Ubuntu) "ubuntu-bug should report touch image information" [Undecided,Incomplete] | 18:54 |
| pitti | cjohnston: ah, I hope that system-image-cli won't actually need root | 18:55 |
| pitti | cjohnston: thanks, I'll play with this | 18:56 |
| cjohnston | barry: ^ | 18:56 |
| cjohnston | I don't know if it does or not | 18:56 |
| barry | pitti: system-image-cli needs root to do updates, but should not need it for --info | 18:56 |
| barry | (i'd say it would be a bug if that were the case ;) | 18:57 |
| barry | --info/--help/--version that sort of thing | 18:57 |
| barry | (basically, if it doesn't need to download anything, it shouldn't need root) | 18:57 |
| cjohnston | cool.. thanks barry | 19:00 |
| barry | pitti: btw, i'm playing with py-dbusmock. looks quite nice. i gather by adding a template, i can make mocks "do things" in response to methods, right? e.g. wait 3 seconds then send signal foo | 19:01 |
| slangasek | smb: and reproduced in a vm now too, so progress | 19:36 |
| pitti | barry: yes; you can do anything templates can do in your normal test cases, but it makes sense to write templates for common services (such as NM or logind) | 20:01 |
| barry | pitti: i'm actually trying to mock the new ubuntu-download-service so i can continue to make progress while the real service is fixing some critical bugs. it might make sense to keep the mock anyway later. but anyway, thanks for this useful package. i filed a bug and may push some mps as i go. | 20:03 |
| pitti | barry: right, that's the idea -- as soon as you encounter the second place that needs that mock, generalize and put into p-dbusmock | 20:08 |
| barry | pitti: +1 | 20:08 |
| cyphermox | stgraber: poke | 20:40 |
| cyphermox | stgraber: know anything specific about /sys/fs/cgroup/memory/lxc/memory.use_hierarchy ? | 20:40 |
| === freeflying_away is now known as freeflying | ||
| YokoZar | So, I've noticed over the years that a lot of Wine games don't work because of performance reasons, and in turn I've discovered that a lot of those performance problems are solved if you force the CPU to run at 100% through a tool like cpufreq -- this even happens on desktop systems and laptops with 100% battery on AC power. | 21:16 |
| YokoZar | I'm wondering what sort of rabbit hole I'll climb into if I try to get a handle on power management configuration, and more specifically how much of this is distro-specific. | 21:17 |
| YokoZar | It strikes me as a serious bug that the cpu isn't upscaling to 100% when a cpu-bound app is run in Wine, but I'm not 100% sure what to file the bug against | 21:17 |
| stgraber | YokoZar: you'll likely end up crying once you figure out that it's mostly caused by broken firmware | 21:18 |
| ChogyDan | YokoZar: that is part of the kernel, cpu frequency governers. And I think you would file upstream | 21:18 |
| stgraber | YokoZar: most of my machines here are reasonable, the kernel defaults to ondemand and the scaling happens as you'd expect with the policy changing when switching between AC and battery | 21:19 |
| sarnold | YokoZar: a few thoughts: (a) I've seen something like gnome-cpu-indicators (or whatever) actually dicking around with the CPU -- make sure you're not also running something stupid like that (b) what governor are you using? performance vs powersave, it'd make a difference. again I think some "power management" contraptions might try to manage those for you. | 21:19 |
| stgraber | YokoZar: but you need a machine with an ACPI that's not completely messed up for that :) | 21:19 |
| YokoZar | sarnold: I've seen it on a wide variety of machines, even "supported" stuff like System76 laptops. Or AWS nodes! In trying to mitigate it by manually forcing everything to 100% I have discovered some conflicting stuff, but it isn't quite default. | 21:20 |
| stgraber | example, all my cores are currently at 1.2Ghz, if I start "yes | sha1sum", one of the core (two threads) instantly go to 2.9Ghz | 21:21 |
| barry | pitti: if you're still around. does running dbusmock on a system bus require sudo? http://paste.ubuntu.com/6103403/ | 21:21 |
| stgraber | and that's default saucy, no config whatsoever | 21:21 |
| YokoZar | stgraber: Yeah that sounds like how it should work. But nevertheless when I do something like install indicator-cpufreq and force it to "performance" my game goes from 12 fps to 40 fps | 21:22 |
| stgraber | so it may be interesting to get some stats, what subset of machines don't default to ondemand and why, then for those that use ondemand, figure out why some don't scale as quickly as they should | 21:22 |
| YokoZar | (on a few different systems) | 21:22 |
| YokoZar | I feel like we don't test this case at all really | 21:22 |
| ChogyDan | YokoZar: I had issues with ondemand. I lost about %30 performance for cpu bound applications | 21:22 |
| ChogyDan | anyway, this is better for offtopic | 21:23 |
| stgraber | YokoZar: I guess letting the user tweak some of those in the settings may be interesting, though I doubt we can simply do things like force performance when on AC | 21:23 |
| stgraber | YokoZar: as quite a few new systems overclock in such cases and can't sustain it indefinitely (well, they should, but there again, firmware usually sucks, so you'll probably reach the trippoint and your machine will just shutdown) | 21:24 |
| sarnold | ouch | 21:24 |
| YokoZar | stgraber: There is firmware that does that. I remember having a demo set up and discovering that if we unplugged/replugged the laptop it would forever lose its performance mode until manually reset | 21:24 |
| stgraber | YokoZar: yeah, you can decompile your DSDT table to figure out exactly what those triggers are and if you feel like it, fix some of those. | 21:25 |
| stgraber | I suspect they just ship fixed/tweaked tables as part of their drivers on Windows and just swap them so they don't get the same problems there (since people are usually bad at updating their firmware...) | 21:26 |
| ChogyDan | YokoZar: Im curious, could you try fiddling with sampling_down_factor, and see if that changes things for you? | 21:30 |
| === freeflying is now known as freeflying_away | ||
| YokoZar | ChogyDan: when I set it to 3 instead of 1 (while on ondemand governor) I did see more consistent "max" fps -- with it on 1 it would occasionally drop down for a second or two. I've seen wildly different performance on this machine (including on default settings), I'm beginning to get a sense this is a much bigger real world problem | 21:50 |
| ChogyDan | YokoZar: try 200. 1 is just disabled, 3 is barely anything | 21:50 |
| ChogyDan | YokoZar: basically, it is a time based factor that delays ondemand's scaling the frequency back down. So *1 is default behaviour. * other numbers, it increases the max freq time exponentially I believe, | 21:52 |
| sarnold | hrm, the archlinux wiki page suggests that changes how often checks are made | 21:53 |
| sarnold | if the cpu -could- be scaled down at a given check, it'd keep it down for a while | 21:53 |
| ChogyDan | sarnold: I dunno, the idea was about keeping it up I thought | 21:54 |
| sarnold | ChogyDan: going entirely by this one wikipage, it looks to me like it's about reducing the overhead of the checks.. | 21:54 |
| sarnold | ChogyDan: ohhhhh, maybe i'm wrong, "This tunable has no effect on behavior at lower CPU frequencies/loads. " | 21:55 |
| ChogyDan | sarnold: well, it does do that, since it delays ondemand from checking so often | 21:55 |
| ChogyDan | sarnold: this is probably the one thing of linux that I'm aware of beyond the reading documentation. I've filed a single bug upstream, and it was about the poor performance of ondemand. The sampling_down_factor patch was proposed as a possible performance boost and solving of my issue. So I read through the patch, but since I'm bad at compiling kernels, I haven't actually tested it much | 22:07 |
| === salem_ is now known as _salem | ||
| OvenWerks | YokoZar: I don't know if this would help, but I found I got better performance (latency wise) with freq set to user and forced to half speed than with on demand. It seems even though the cpu speed switch is very quick I was getting audio under runs at ondemand speed switching. It might interesting to try other speeds than just performance. Also, The application may be settings its max frame rate bassed on idle performance before the higher speed kicks | 22:12 |
| YokoZar | OvenWerks: Yeah, it's entirely possible the game is too smart in a lot of cases | 22:13 |
| OvenWerks | Running a high cpu use do nothing app when startiing the game up? :P | 22:14 |
| stgraber | hallyn_: cyphermox reported: | 22:15 |
| stgraber | root@castiana:~# echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy | 22:15 |
| stgraber | bash: echo: write error: Device or resource busy | 22:15 |
| stgraber | hallyn_: isn't that supposed to work? :) | 22:15 |
| hallyn_ | stgraber: it doesn't work once there is already a subdir | 22:16 |
| stgraber | hallyn_: haha, that explains it, thanks | 22:16 |
| stgraber | cyphermox: ^ | 22:16 |
| hallyn_ | yup. it's actually one reason to stick with /lxc/%n as cgroup_pattern, i guess | 22:16 |
| cyphermox | ok, so it means we don't need to rerun it or what? | 22:17 |
| hallyn_ | what is it set to | 22:17 |
| stgraber | cyphermox: if you have a script doing the echo, just do it at boot time, before LXC in /sys/fs/cgroup/memory/memory.use_hierarchy | 22:18 |
| stgraber | cyphermox: I assume that this should then get inherited by everything that gets created after that point | 22:18 |
| stgraber | cyphermox: (and I just confirmed it) | 22:18 |
| cyphermox | cool, sure | 22:19 |
| cyphermox | thanks | 22:19 |
| stgraber | np | 22:19 |
| cyphermox | that happens before we start the container | 22:19 |
| sarnold | ChogyDan: funny enough I did wonder if the code would be easier to understand.. :) | 22:20 |
| didrocks | stgraber: is this new? | 22:20 |
| didrocks | stgraber: we run it during the pre-mount | 22:20 |
| didrocks | for months | 22:20 |
| stgraber | didrocks: it probably changed behaviour at some point in 3.11 | 22:21 |
| didrocks | ok | 22:21 |
| didrocks | stgraber: actually, we do that in prestart | 22:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!