[00:51] xnox: sadly, that didn't actually help [00:51] hallyn: =/ oh well. [00:52] hallyn: i can try to dig into it, but deffinatly not tonight. [00:52] now really i expected it to make it worse (since noone is using it :) [00:53] xnox: np, it's late there - ttyl [00:53] thanks! gn [00:53] Or as another alternative... is the kernel in the new builds managed by a deb file? [00:55] *new touch builds === _leb is now known as leb === hatch__ is now known as hatch === gerald is now known as Guest85398 === lag is now known as lag` === lag` is now known as lag === henrix_ is now known as henrix [11:38] ParkerR, the kernel is built in a .deb yes though typically upgrades in touch images are not done directly [11:39] the kernel deb is only used by the android package [11:39] (which generates boot.img and system.img (the latter has the modules)) [11:44] just on a sidenote, forcing performance from initrd on boot on mako gains exactly nothing :( [11:55] ogra_, worth a try [11:55] yeah [11:56] it actually takes a few milliseconds longer with performance ... i guess thats due to the echoing "performance" into sysfs [12:13] AHA ! [12:13] root@ubuntu-phablet:/# ls -l /var/lib/ureadahead/debugfs/ [12:13] total 0 [12:13] root@ubuntu-phablet:/# mount | grep debugfs [12:13] none on /sys/kernel/debug type debugfs (rw,relatime) [12:13] so i guess thats why ureadahead doesnt work anymore [12:13] aha? [12:14] well, ureadahead reads from /var/lib/ureadahead/debugfs/ [12:14] doesnt it ? [12:14] isn't that normal? doesn't ureadahead mount it temporarily on its own mointpoint during its run and unmount it after? [12:15] hmm [12:15] as it may need it before it is mounted by the system [12:16] hmm [12:17] ogra_, so actually it uses /sys if it is mounted, else it mounts its own [12:17] ah, k [12:21] ogra_, is there a bug for this ? [12:22] nope, still researching [12:22] funnily it seems ot have profiled something at some point [12:22] *to [12:22] but it is never executed on boot after that [12:22] is the packs directory writable ? [12:23] or ... the place that the "reprofile" marker is stored [12:23] yes [12:23] i see packs that have been generated on first boot [12:23] http://paste.ubuntu.com/7113774/ [12:23] even specoific ones for the container [12:24] have you tried just running it to see if it works? [12:24] it doesnt [12:24] root@ubuntu-phablet:/# start ureadahead [12:24] ureadahead stop/waiting [12:25] callong "ureadahead --daemon" directly immediately returns ... i dont see it in the processlist [12:33] ogra_, and without --daemon and with --verbose ? [12:34] looks ok http://paste.ubuntu.com/7113819/ [12:36] ogra_, ok so you don't see it because it only takes 0.02s to do the readahead, as this is flash it is not that supprising [12:37] it would still show up in a bootchart [12:37] (it used to) [12:37] so that implies it is not starting, which says the start condition is wrong [12:38] i assume we ahve a mountall job still ? [12:40] ogra_, ^ [12:40] yep [12:41] http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-243.png [12:44] infinity: No update to the precise kernel? [12:45] ogra_, there is a level at which things get collapsed when they are tooo short [12:45] hmm [12:46] which you can turn off when generating hte graph [12:47] ah, there is a HZ= setting [12:48] * ogra_ sets it from 25 to 50Hz [12:54] so that gets me a lot more small processes listed (and makes the tgz of the bootchart twice as big) ... but still no trace of ureadahead ... [12:55] now i wonder ... [12:55] ogra_, could still be tooo small to see i be reconing [12:56] yes, the point is that the interesting pack files arent the default pack [12:56] (see my ls output of /var/lib/ureadahead above) [12:56] arn't those loaded by the other job? [12:56] and these mountpoinnts arent handled by mountall [12:56] but before in the initrd [12:57] i.e. they are already mounted when mountall starts [12:57] ok then they won't get loaded anyhow [12:57] start on mounted DEVICE=[/UL]* MOUNTPOINT=/?* [12:57] see /etc/init/ureadahead-other.conf which loads them based on the mount announcements [12:58] so i suspect you want your own job which runs ureadahead against the special mounts [12:58] so the question is, does mountall emit "mounted" for already mounted devices in fstab [12:58] jodh, do you know ?^^^ [12:59] i would doubt it, you can look at the emitted events right? [12:59] i think we dropped "initrcl events" at some point [13:00] "The mounted event is generated by the mountall(8) daemon after it has mounted a filesystem." [13:00] i read that as for things it has mounted itself only [13:01] bah, k [13:01] so i need something that loops through fstab and calls ureadahead for each mountpoint regardless [13:01] and starts on startup or so [13:01] you know your special ones right? [13:01] they are always the same phone wise ? [13:02] well, i guess we want everything but rootfs [13:02] no, but fstab is assembled by initrd on boot [13:02] (on every boot) [13:24] bah, and now i killed my remote device :( [13:53] ogra_: yep, apw is correct. [13:55] * ogra_ tries ureadahead-other with a hardcoded value for MOUNTPOINT ... but that doesnt seem to work either [13:57] ? [13:57] what did you put in there [13:57] ogra_, ^ [13:57] /android/system [13:58] my main concern is to get the container up faster (since most of the other bits have to wait for it) [13:59] i made the ureadahead-other job start on "starting mountall" and replaced the $MOUNTPOINT in the exec line with the path [14:00] i was assuming this should just work [14:00] but i neither see it in the bootchart nor do i notice any speedup ... [14:06] perhaps boot it --debug on the kernle command line to see if it runs [14:07] ogra_: try adding '--force-trace' [14:07] ogra_: also, what's in /var/log/upstart/ureadahead-other.log ? [14:07] jodh, but that will create a new pack ... i have the packs from first boot already [14:07] i just want it to make use of them :) [14:08] ogra_: on those new mountpoints? [14:08] i emptied the log a few boots ago (before i started hacking the job) and there is now nothing in it [14:08] root@ubuntu-phablet:/# ls /var/lib/ureadahead/android* [14:08] /var/lib/ureadahead/android.firmware.pack [14:08] /var/lib/ureadahead/android.persist.pack [14:08] /var/lib/ureadahead/android.system.pack [14:09] so there is one pack for /android/system ... if i read that correctly [14:09] ogra_: ok, have you added --verbose atleast then to get some output? [14:09] not yet [14:09] will do that now [14:09] * ogra_ reboots with --verbose [14:11] root@ubuntu-phablet:/# cat /var/log/upstart/ureadahead-other.log [14:11] nothing ... [14:12] * ogra_ moves the start condition to "started mountall" [14:12] still no log [14:12] aha [14:13] manually starting it produces something in the log [14:13] http://paste.ubuntu.com/7114261/ [14:13] smells like mountall is never emitting "started" or so [14:14] * ogra_ moves to "start on startup" [14:14] lets see [14:15] funny, nothing new in the log [14:15] ogra_: is ureadahead-other.log empty or non-existent? [14:15] ogra_: try running "sudo initctl notify-disk-writeable" and check the log again [14:15] it was empty (because i did "echo > ... " ) ... [14:15] it got conent when i manually started the job [14:16] ogra_: that's cheating :) [14:16] ok, got it [14:16] "start on filesystem" works [14:16] now it writes to the log on every boot [14:17] * ogra_ dropes the --verbose and creates a bootchart [14:17] *drops [14:18] i dont get why "start on startup" didnt work though [14:18] maybe you don't have the ureadahead daemon availabe then [14:19] and it would want to write to teh ro filessytems anyhow [14:19] nope [14:20] the filesystem is assembled from initrd [14:20] it is fully set up before we even get to the rootfs [14:20] with all writable bits [14:20] and now i see ureadahead in my bootchart \o/ [14:20] finally [14:21] but it doesnt speed up anything :( [14:22] ah, no, it gains me .5 sec [14:22] lxc-start runs half a sec earlier now [14:23] what a great gain for half a day of work :P [14:27] ogra_, thats pretty good :) [14:29] well, lets see, i guess i can write a loop script that processes all packs (apart from the default one) [14:29] that might in the end get me 2sec then :P === hatch__ is now known as hatch === cmagina is now known as cmagina-away [14:47] yeah it might === hatch is now known as negatron === negatron is now known as hatch [14:54] ** [14:54] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [14:54] ** === cmagina-away is now known as cmagina [14:58] cking: so is thermald a dependency of something? what pulls it in? should I install it? [14:59] mdeslaur, just install it [14:59] cking: is something going to install it by default on our images? [14:59] for t+1 we will make it a dependency on the kernel [14:59] but for now it's an opt-in [15:00] it still is a "maturing" daemon [15:00] cking: ok, thanks! === cmagina is now known as cmagina-away === cmagina-away is now known as cmagina === cmagina is now known as cmagina-away [15:09] hallyn, ok this is occuring because you have to have read/execute access to all layers in a directory "sandwich" to read the directory [15:10] hallyn, i am trying to figure out if this is an oversite of a deliberate decision [15:13] apw: yeah it seemed possible to be on purpose, but i couldn't find where in the code itw as doing it [15:15] hallyn, you are hitting the opendir behaviour there, where it opens each dir in each layer and merges the contents to make the virtual dir you see [15:15] so if you make the bottom directory rx the you can see in there as well [15:16] and i asusme the under in your scenario is empty as well === cmagina-away is now known as cmagina [15:18] hallyn, and the permissions check is specifically checking all layers, it is not an accident [15:18] hallyn, it has a little loop for when we are talking about a read from a directory [15:21] hallyn, i assume this comes from using an unmodified directory image as a lower level here ? [15:21] apw: it may nto be an accident, but is it worthwhile? [15:21] yes [15:21] overlayfs doesn't do it... [15:22] overlayfs is much less mature, so that tells me little about which is right [15:24] what is it stopping you doing [15:24] apw: juju creates a clone of a stock ubuntu image, then wants to chown ubuntu: /etc/ssl/private [15:25] apw: thinking sensibly about the behavior, I really think aufs is the one in the wrong [15:25] i think you need to justify that [15:25] sure, [15:25] to do the chown you have to be root in the first place, [15:26] you can't end up corrupting the underlyign fs, you can only 'leak' data through the upper fs, [15:26] but since you're root, you *could* just as well do it to the underlying fs. there is no reasonable case i can think of where you werne't meant to 'leak' the data in the file you're chowning [15:30] zequence: Nope. [15:43] hallyn, ok that needs some thinking about and upstream discussion i am sure, i'll see if i can fix it as a basis or that discussion [15:48] apw: ok, thanks. i'll watch for the thread. [15:49] apw: if upstream nacks it, then i guess we'll just have to issue a warning somewhere in lxc [15:49] (or drop aufs from lxc clone support - stgraber :) [16:19] hallyn: Well, juju could hack around the issue with 'cp -a /etc/ssl/private /etc/ssl/private.new && rm -r /etc/ssl/private && mv /etc/ssl/private.new /etc/ssl/private' [16:19] With a chown in there somewhere. [16:19] Not that that's ideal, but would get you over the hump for now. [16:19] infinity: for that particular case, yeah. but if we're goign to suggest that aufs is usable for lxc clones, that's not sufficient [16:20] like i say every backing store has its deficiencies for clones, but that's just not usable [16:20] hallyn: Not usable is a bit extreme. How often does one actually try to do that (traverse a directory they can't read)? [16:21] Is that chown happening in an unprivileged container, or outside? [16:21] (ie: do you have real root?) [16:21] If you have real root, I agree that the behaviour seems entirely wrong. [16:21] If you don't, I'm not sure how you're reading it at all, seems like a different bug being leveraged. :P [16:22] infinity: i don't think real root matters. [16:22] if i create a rootfs, [16:22] then create an aufs clone container from that unprivileged, it shoudl be the same situation [16:22] uid 100000 (my root) chowns a dir to uid 1001000, [16:22] but uid 1001000 can't read it despite owning it [16:23] maybe instead of not suable i should have said not supportable :) [16:24] (as in we'll get tons of weird bug reports) [16:24] I'm struggling to even find a 750 directory in my schroots to experiment with. :P [16:25] Ahh, hello /var/cache/ldconfig [16:26] Okay, yeahp, has nothing to do with containers at all, that's what I wanted to make sure of. [16:26] (trusty-amd64)adconrad@cthulhu:/var/cache$ ls -al | grep ldconfig [16:26] drwx------ 2 adconrad adconrad 60 Mar 18 10:25 ldconfig [16:26] (trusty-amd64)adconrad@cthulhu:/var/cache$ ls ldconfig/ [16:26] ls: cannot open directory ldconfig/: Permission denied [16:26] That seems fundamentally broken to me. [16:27] the only way it would be needed is if aufs wrongly allowed non-root to chown the dir [16:27] or, does aufs support some fancy uid translation gorp? /me checks [16:28] not sure waht the 'different uid/gid/permission' in mount.aufs manpage is referring to [16:53] most of the docs are in janglish [16:54] ## [16:54] ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting [16:54] ## [17:06] * ppisati -> chest press === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 25th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:50] Why is the Lustre FS in staging? [17:51] It can be used from userspace and none of the desktop or notebook users will ever use it. You have a greater chance of someone using the tdfx support. [17:51] why do you ask downstream ? [17:52] thats a question for the people that decided to put it in stagint (the linux kernel ML for example) [17:52] Ubuntu has made additions and subtractions [17:52] Don't play that game. [17:53] This is pure bullshit bloat for something that should be in userspace on non-niche distros [18:03] UserError, why are we worrying about 1.3M ? [18:03] 10MB [18:04] for a feature no-one will ever use and will also be in VM kernels by default [18:04] i can only find one module, which is 1.3M, and why would it be in VMs [18:04] according to the latest staging on 3.13.5 [18:04] it is nearing 10MB on 64bit [18:05] which is the only one worth using since 32bit still targets i686 [18:06] apw, Ubuntu stated the reason it wasn't including that vpadu stuff was because of ISO size [18:06] So i started figuring out that the reasoning was bullshit [18:06] By going through every single file that was useless. Now i'm on the kernel. [18:07] Way to keep PandaBoard and Tegra shit in an x86 FS [18:07] and exynos in the kernel [18:12] so build your own kernel with what you want in it [18:13] not that the size of them in the filesystem tells you waht they are on the iso [18:14] Ignore the bloat behind the curtain until you make your own curtain [18:14] Nevermind that Exynos = ARM [18:15] it is a trade off between the greatest usability against the effort to work out what is completely unusable [18:15] It isn't usability if it is impossible to use [18:15] Please, please use an x86 kernel on a exynos SoC [18:16] if the config system says something is usable, turning it on is therefore the default position, if the thing is actually configurable but useless would require individual items to be investigated [18:16] so i am sure we have a number of things turned on which cannot be used, due to the lack of correct dependancies [18:16] ARM =/= X86 [18:17] what is the problem [18:17] Nothing is going to change that [18:17] you are not hearing me, i am telling you how one ends up in this position [18:17] you may have found a clear case indeed and if someone files a bug for it, we may indeed turn it off [18:18] i am saying that these cases are not clear wthout investigation [18:18] Ok fine, FS wise, off the top of my head [18:18] alsa package [18:18] kernel wise, hw arch exynos [18:19] Also some TI stuff in there i have the path to somewhere [18:20] yep and if someone has the configuration options and the justificaiton, and puts them in a bug [18:20] there is a high probability it will get looked at and turned off [18:21] Right but the flaw is the fact that it could've been added from the beginning when the same SoC is powering the phones of the people who should know better [18:21] when every kernel update has hundreds of new options one has to have a default position [18:21] and that is to turn on things which the config system says are applicable to an arch [18:22] and if we have 100 engineers looking at the config then it would likely be perfect [18:23] you could literally just use grep on the config with the major arm licensee models [18:23] i could go and save space on a machine whiich on average doesn't care [18:23] or i could go and work on some new feature we need [18:23] which is it [18:24] right, which is going to harm the idea of ubuntu touch and other modile ideas [18:24] nope they have non-generic kernels which are much much smaller [18:24] when you are having that many writes on every security update [18:24] every hyrbid device with similar nand/emmc to a phone [18:25] all those writes [18:25] and touch devices have a minimal config, so this does not apply [18:25] all the VMs and appliance containers [18:25] you assume they are minimal, i beg to differ [18:25] and the VMs do not have the entier kernel installed [18:25] there is a split, between the core bits needed on a virtual system, and the rest [18:26] you're right, they only have joystick nonsense by default [18:26] and sound [18:26] i am sure they have some bits they should not indeed, but they are less than a third of the size of the full ones [18:27] and if you have some concrete config changes you thing are viable, feel free to propose them [18:27] along with a testing plan [18:27] The thing is that this has a commutative impact [18:28] what is the launchpad for this [18:28] i asume you are asking what package to file bugs against, that would be 'linux' [18:29] but "your package is crap" isn't going to get much attention, concrete changes would likely [18:29] pretty much removal [18:29] the package is crap [18:30] i went through every file on sunday [18:32] what is vpadu [18:33] vdpau* [18:33] http://www.phoronix.com/scan.php?page=news_item&px=MTYwNzU [18:34] "too big" [18:34] yet the kernel can grow by tens of MB in a day [18:35] yet panda and tegra can just chill in alsa never to be used ever by anyone [18:35] frankly though i may even agree that we have a lot of bloat, your attitude is getting to me [18:35] * ogra_ wonders if UserError is like that in real life too [18:40] i dunno, i am nicer on irc than in real life in general [18:41] heh [18:42] to which i am sure you can attest :) [18:42] well, when i meet you in person you are usually drunk already :P [18:43] i tend to mellow after enough of that [18:43] (but i'm usually in the same state) [18:43] Is there any plan to make the 32bit kernel or X11 / toolkit / MIR visual packages useful by targeting anything other than the PentiumPro platform with zero optimizations for hardware that actually fits the ram and CPU minimums? [18:43] UserError: Why would we build a 32-bit kernel that doesn't run on 32-bit hardware? [18:44] (Hint, you can install the amd64 kernel with a 32-bit userspace, if that's what you're after) [18:44] i686 with a single chipset that supports a theoretical minimum on one hand is insanity [18:44] not what i am talking about [18:45] If the recommended minimum for many packages is 800-1Ghz, and only one i686 era CPU can meet those marks on a quad setup that threads horribly... [18:46] Intel even proved that the major reason 64bit was faster was optimizations [18:46] Err, they did? Neat trick. [18:46] yeh, they did [18:46] in 2012 [18:46] The major reason x86_64 is faster is lack of register pressure. [18:47] http://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints [18:47] cough [18:47] For some things like string functions, optimisation can make a huge difference, but you get that regardless. [18:47] Because IFUNC is a beautiful thing. [18:47] UserError: That page appears to contain nothing to support your assertion [18:48] People are holding back performance on 32bit because of a single chipset [18:48] indeed it seems to support the contention that increased registers is a ke factor [18:48] mjg, the gain difference with the same CPU [18:48] key [18:48] because of initial targeting of SSE2 vs nothing [18:48] i686 is nothing [18:56] In a few months it will be the birthday of the MMX instruction set. [18:56] Still lacking, since 1997 http://download.intel.com/support/processors/pentiummmx/sb/24318504.pdf === retoaded is now known as retoaded_afk === cmagina is now known as cmagina-away [22:25] zequence: You happy with the kernels in your PPA? [22:27] zequence: Nevermind, they look good to me, copying. === alai is now known as alai_afk [22:39] submitted the exynos and lustre paths [22:39] on to the nitty gritty [22:59] UserError: Is all this really fallout from one article quoting one guy as to why he's not shipping and supporting a mesa driver? [22:59] No [22:59] Sure sounded like it. [23:00] I'm just removing the excuse of the diff as icing on the cake. I actually am super anal about bloat [23:00] but their words did get plenty of my side-eye === emma__ is now known as emma