[09:46] <ogra_> ppisati, whats that about dropping arm board support ?
[09:46] <ogra_> (why dont you just leave them idle ... so people can potentially use them)
[09:50] <ppisati> ogra_: because we don't need them
[09:50] <ogra_> well, users might use them :)
[09:51] <ppisati> ogra_: if we find someone actually using them, they can send a req to turn them on again
[09:51] <ogra_> that would save them from having to roll their own
[09:51] <ppisati> ogra_: we already have enough dead crap in it
[09:51] <ogra_> heh, ok
[09:52] <rtg> ppisati, aren't these for platforms that don't support LPAE ?
[09:52] <ppisati> rtg: both of them
[09:52] <rtg> ah
[09:52] <ppisati> rtg: in the lpae case we just support calxeda and vexpress a15
[09:53] <ppisati> rtg: for the non-lpae case, we support omap3/4, imx, calxeda and vexpress
[09:53] <ppisati> 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] <ogra_> omap5 devices are rare and hard to find
[09:54] <ogra_> (was born dead after omap4 was discontinued)
[09:55] <ppisati> ogra_: don;t you have an exynos5 laptop?
[09:55] <ppisati> ogra_: are you willing to test a kernel?
[09:56] <ogra_> yes as my main work machine with a highly hacked up GLES setup
[09:56] <ppisati> ah, right
[09:56] <ogra_> dont really want to risk that 
[09:56] <ppisati> the GL bound...
[09:56] <ogra_> yeah
[09:56] <ppisati> :(
[09:57] <ogra_> i would have said ask hrw, but he is all fedora now 
[09:57] <ppisati> fedora?
[09:57] <ogra_> EH hired him
[09:57] <ogra_> *RH
[09:57]  * ppisati thinks should ask to expense one and add exynos5 support to out generic multiplatform kernel
[09:57] <ogra_> ++
[09:57] <ogra_> you should really have a chromebook 
[09:58] <ppisati> well, problem is that they were talking about a refreshment soon, so i was waiting for that to happen
[09:58] <ogra_> enoxys5 + USB 3.0  + 2GB = priceless
[09:58] <ppisati> ah, and i would go for a GL-less kernel :)
[09:59] <ogra_> my last refreshment paid for 3 ac100s and the chromebook :)
[09:59] <ogra_> (well, technically i got one ac100 for free)
[09:59] <ppisati> ogra_: i mean refreshment of the chromebook line
[09:59] <ogra_> ah
[09:59] <ogra_> not sure if they will do an arm one again
[10:00] <ppisati> http://gigaom.com/2013/05/31/new-samsung-chromebook-may-use-8-core-chip-for-power-and-performance-boost/
[10:00] <ppisati> it was all over the internet
[10:00] <ogra_> oh, then it must be true :)
[10:00] <ppisati> LOL :)
[10:00]  * ogra_ goes reading
[21:54] <anon^_^> 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] <infinity> anon^_^: We build in all the mainline schedulers.  There's not much interested in pulling in out-of-tree ones, AFAIK.
[22:57] <anon^_^> inifinity, the main reason I brought it up is there are still some desktop responsiveness issues with deadline and multi-tasking
[22:57] <anon^_^> specifically when initiating and maintaining sustained file transfers
[22:58] <anon^_^> BFQ seems to handle those scenarios well and could be more suitable for desktop use
[23:01] <anon^_^> 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] <infinity> 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] <infinity> 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] <anon^_^> Unfortunately, my magic wand can't make that happen, but I can petition the ubuntu kernel team
[23:09] <infinity> You could also petition upstream.  Just sayin'.