=== dduffey_afk is now known as dduffey === ohsix_ is now known as ohsix === smb` is now known as smb [09:46] ppisati, whats that about dropping arm board support ? [09:46] (why dont you just leave them idle ... so people can potentially use them) [09:50] ogra_: because we don't need them [09:50] well, users might use them :) [09:51] ogra_: if we find someone actually using them, they can send a req to turn them on again [09:51] that would save them from having to roll their own [09:51] ogra_: we already have enough dead crap in it [09:51] heh, ok [09:52] ppisati, aren't these for platforms that don't support LPAE ? [09:52] rtg: both of them [09:52] ah [09:52] rtg: in the lpae case we just support calxeda and vexpress a15 [09:53] rtg: for the non-lpae case, we support omap3/4, imx, calxeda and vexpress [09:53] if anyone is willing to support (aka test) exynos5, st, omap5, etcetc i'm happy to turn them on [09:54] * ogra_ thinks am43xx (beaglebone) would be more intresting than omap3 [09:54] omap5 devices are rare and hard to find [09:54] (was born dead after omap4 was discontinued) [09:55] ogra_: don;t you have an exynos5 laptop? [09:55] ogra_: are you willing to test a kernel? [09:56] yes as my main work machine with a highly hacked up GLES setup [09:56] ah, right [09:56] dont really want to risk that [09:56] the GL bound... [09:56] yeah [09:56] :( [09:57] i would have said ask hrw, but he is all fedora now [09:57] fedora? [09:57] EH hired him [09:57] *RH [09:57] * ppisati thinks should ask to expense one and add exynos5 support to out generic multiplatform kernel [09:57] ++ [09:57] you should really have a chromebook [09:58] well, problem is that they were talking about a refreshment soon, so i was waiting for that to happen [09:58] enoxys5 + USB 3.0 + 2GB = priceless [09:58] ah, and i would go for a GL-less kernel :) [09:59] my last refreshment paid for 3 ac100s and the chromebook :) [09:59] (well, technically i got one ac100 for free) [09:59] ogra_: i mean refreshment of the chromebook line [09:59] ah [09:59] not sure if they will do an arm one again [10:00] http://gigaom.com/2013/05/31/new-samsung-chromebook-may-use-8-core-chip-for-power-and-performance-boost/ [10:00] it was all over the internet [10:00] oh, then it must be true :) [10:00] LOL :) [10:00] * ogra_ goes reading === Eimann_IETF is now known as Eimann === kloeri_ is now known as kloeri [21:54] Hi, I'm sure this topic has been discussed or covered before, I can't seem to find an answer. Has the kernel team considered including BFQ in a kernel package? possibly in linux-lowlatency? [22:56] anon^_^: We build in all the mainline schedulers. There's not much interested in pulling in out-of-tree ones, AFAIK. [22:57] inifinity, the main reason I brought it up is there are still some desktop responsiveness issues with deadline and multi-tasking [22:57] specifically when initiating and maintaining sustained file transfers [22:58] BFQ seems to handle those scenarios well and could be more suitable for desktop use [23:01] including BFQ (but not set as default), would at least allow users to switch schedulers and still maintain the use of ubuntu kernel in repo [23:07] Convincing zequence to pull it into lowlatency might be an easier sell. Still, maintaining out-of-tree patches can be a pain, especially if we want to move befre BFQ upstream does (he doesn't seem to release patches against RC kernels, for instance) [23:08] Honestly, the best answer for everyone is, instead of evangelizing how awesome it is for years, and asking distros to carry it as a patch, get it cleaned up and in mainline. [23:09] Unfortunately, my magic wand can't make that happen, but I can petition the ubuntu kernel team [23:09] You could also petition upstream. Just sayin'.