| ZaggeO | does anyone know what is the reason that xhci_hcd is compiled into the kernel and is not as a module | 10:27 |
|---|---|---|
| mlankhorst | why is it important to you? | 10:32 |
| ZaggeO | mlankhorst: it sometimes blocks suspend of the kernel and without being a module I can't unload to make suspend work | 11:29 |
| apw | ZaggeO_, iirc they are compiled in else you cannot ensure that usb3 things are found by that first | 11:42 |
| ZaggeO_ | apw: what might not be found? | 11:47 |
| ZaggeO_ | apw: you mean during bootup or in general? | 12:09 |
| apw | in general | 12:09 |
| apw | i believe | 12:09 |
| apw | as i think usb2 can be loaded in responce to a device, then it will always take everything | 12:10 |
| apw | and so usb3 is never loaded, something like that | 12:10 |
| ZaggeO_ | apw: it is a module on my debian machines and it works without problems there. It used to be a module on ubuntu too some releases ago | 12:11 |
| apw | indeed, and we changed it because it was an issue | 12:11 |
| ZaggeO_ | since then I have the issue that my kernel sometimes no longer suspends and I need to reboot | 12:12 |
| ZaggeO_ | and quite often I don't notice it and then the battery runs out in my backpack and when I want to use it again it is empty | 12:13 |
| ZaggeO_ | apw: is there a different stock kernel one could use without the need to compile my own kernel? | 12:15 |
| apw | all our stock kernels have essentially the same config | 12:16 |
| apw | you should file a bug for it, perhaps it can be fixed the suspend issue | 12:17 |
| ZaggeO_ | apw: what kind of infos should I attach to the bug report? | 12:22 |
| apw | everything you said above at least | 12:27 |
| hallyn | sforshee: hey, so tried out fuse-ext2 in a container. Created loopback on host with ext2; created /dev/loop0 in container; used fuse-ext2 to mount htat. could only mount read-only. is that expected? (I assume so, but am not sure based on your intro email why) | 13:33 |
| sforshee | hallyn: you have to supply -oforce with fuseext2 to get a rw mount | 13:39 |
| sforshee | hallyn: also you don't have to mess with loop if you don't want to, you can give it the name of an fs image file | 13:42 |
| hallyn | sforshee: thanks | 13:43 |
| hallyn | think i'll set up some package builds in and out of that fs and see how the timings compare | 13:44 |
| hallyn | sforshee: smoser: wow, completely naive test (timing building of lxc package exactly once) shows fuse-ext2 being faster than the container's native ext4 | 14:19 |
| hallyn | I suspect ocne I start some page cache clearing that'll change, | 14:19 |
| hallyn | but still that completely belies smoser's argument that fuse can't be good enough :) | 14:20 |
| smoser | you dont think that runnning all reads and writes through user space is faster than the kernel ? | 14:20 |
| smoser | if it turns out that ext4 via fuse is as fast as in-kernel ext4 | 14:21 |
| smoser | then... um... that is really bad. | 14:21 |
| smoser | embarrassingly bad from the kernel ext4 perspective | 14:21 |
| hallyn | well i didn't compare to a *real* fs :) | 14:22 |
| sforshee | hallyn: that's interesting, I wonder if that will hold over multiple test runs | 14:26 |
| sforshee | and if it does I'd really like to know why | 14:26 |
| hallyn | sforshee: multiple runs, probably. I'm guessing the data never even hit disk | 14:28 |
| sforshee | hallyn: it would be more apples to apples to compare ext2 in kernel to ext2 in fuse | 14:28 |
| hallyn | so bigger runs, where i start swapping page cache, will probably get a hit | 14:28 |
| hallyn | sforshee: i thought fuse-ext2 was actually doing ext4 | 14:28 |
| sforshee | hallyn: possible, but would it have hit disk in the normal case? I assume you were using loop. | 14:29 |
| hallyn | Yeah, using loop | 14:29 |
| hallyn | for the fuse fs | 14:29 |
| sforshee | I don't think fuse has any driver for ext4. afaik fuseext2 supports ext2 and ext3 only | 14:29 |
| hallyn | and no, it wouldn't have hit disk in normal case either - which is the confusing part. | 14:29 |
| hallyn | hm | 14:29 |
| hallyn | well ext4 is supposed to be way faster no? :) | 14:29 |
| sforshee | dunno, there's definitely more complexity | 14:30 |
| hallyn | anyway i wasnt out to do a *good* comparison this morning; i only wanted a "this isn't completely unusable" comparison | 14:30 |
| sforshee | I wonder if cking has any benchmarks for ext2 vs ext4 | 14:30 |
| * hallyn waits for smoser to more explicitly suggest that we should all be using microkernels | 14:31 | |
| sforshee | though these days we're using the ext4 driver even for ext2 | 14:31 |
| cking | sforshee, nope, but I can add them to the mix | 14:34 |
| smoser | yeah, its caching. | 14:34 |
| smoser | same reason that loop is faster than direct sometimes :) | 14:34 |
| smoser | thats the only thing i could figure. | 14:34 |
| sforshee | smoser: but I think both cases should be cached, that's why I'm confused | 14:35 |
| sforshee | we' | 14:35 |
| sforshee | we'll just wait and see what further testing shows I guess | 14:35 |
| cking | smoser, maybe metadata writes are being cached more when on the loop | 14:35 |
| smoser | i never understood that. | 14:35 |
| sforshee | cking: not more than when going through fuse I suspect | 14:35 |
| smoser | but lots of times people report loop being faster than non-loop | 14:35 |
| smoser | oh. well. i thikn that 'fsync' doesnt actually fsync | 14:35 |
| smoser | through loop | 14:35 |
| smoser | is that the case ? | 14:36 |
| cking | smoser, the "advantage" of more dirty pages being cached and that extra layer may give some advantage I guess | 14:36 |
| smoser | i sweare i read that once. that loop devices had no fsync. but i'm clearly in over my head here :) | 14:36 |
| sforshee | smoser: I don't know for sure, but I'd guess that it only syncs to the backing file and not all the way through to the disk | 14:37 |
| smoser | right. | 14:37 |
| smoser | thats what i had thought. | 14:37 |
| smoser | which would mean a spinning disk would be slower when the fsync was actually forced to go to it. | 14:37 |
| sforshee | right | 14:38 |
| cking | i guess we can speculate to the cows come home, whereas using perf may tell us what's actually happening | 14:39 |
| ev | arges: hi. Would you be able to help me find out if nested kvm is something you guys are willing to support? Running the Touch emulator on Canonistack gives me unhappy results: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347737 | 14:49 |
| ubot5 | Launchpad bug 1347737 in linux (Ubuntu) "Kernel nested kvm support" [Undecided,New] | 14:49 |
| arges | ev: hi, taking a look. nested KVM should work, but there are some hardware dependent issues that can occur | 14:49 |
| ev | in that case, let me get you some more details on the VM | 14:50 |
| ev | or do you mean the compute node's hardware? | 14:50 |
| arges | ev: well both will be relevant | 14:50 |
| ev | presumably the latter :) | 14:50 |
| ev | ah, right | 14:50 |
| arges | ev: so what is a bit confusing is that you are running on i386, but the VM is ARM arch? are you emulating? | 14:52 |
| * ev bangs his head on the desk | 14:53 | |
| ev | let's try this with x86 on x86, shall we | 14:53 |
| arges | ev: : ) | 14:53 |
| xnox | why shan't we ;-) | 16:28 |
| xevious | Will dmsetup remove flush any buffers for the device prior to removing it, or should sync be run manually? If I do need to sync manually, would `blockdev --flushbufs /dev/mapper/name` accomplish what I need? For reference, I'm concerned because of this: http://www.redhat.com/archives/dm-devel/2012-January/msg00082.html Has this been patched in recent versions of Device Mapper? If so, which version? | 18:23 |
| Hauke | apw: I created a bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1347879 | 19:52 |
| ubot5 | Launchpad bug 1347879 in linux (Ubuntu) "Compile problem with external module and 031600rc5" [Undecided,New] | 19:52 |
| rtg | Hauke, I'm about EOD, but I'll look at it in the AM | 20:08 |
| Hauke | rtg: thanks | 20:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!