[07:18]  * smb yawns
[07:21] <cooloney> smb: morning,
[07:21] <smb> cooloney, Morning, how are things going?
[07:22] <cooloney> smb: i'm good, just went through the kernel config about cgroups, looks like there is not much change we need to do
[07:23] <cooloney> smb: could you please share the link for me again about the review cgroups config task
[07:23] <smb> cooloney, Ah, good it is not too much. Though I take it some things are still missing... Sure, give me a sec
[07:24] <cooloney> smb: thanks. 
[07:26] <smb> cooloney, It is not directly the link to the workitem, but this may be even more useful: http://status.ubuntu.com/ubuntu-quantal/u/cooloney.html
[07:27] <smb> The link for the cgroups stuff is in the work item details
[07:27] <cooloney> smb: wow, thanks a lot, i searched a lot but failed to find out this
[07:27] <smb> cooloney, It is a good place to look whether someone gave you a work item without telling you. ;)
[07:27] <cooloney> smb: for the CFQ and deadline discussion, i plan to reply to the reporter about cking's evaluation
[07:28] <cooloney> smb: and ask for some hard facts in detail
[07:28] <smb> cooloney, Is that your friends or theother reporter?
[07:29] <smb> I think from the other report it is at least clear that it is related to kvm and the emulated disk
[07:29] <cooloney> smb: i sent out an email, did you see that
[07:29] <smb> cooloney, I just started my email and begin to drink some coffee, don't expect too much, yet... :-P
[07:31] <cooloney> smb: echo 10 > /proc/sys/kernel/hung_task_timeout_secs
[07:31] <cooloney> And start some parallel reads and writes. After a while dmesg will
[07:31] <cooloney> have some warnings about flusher being blocked.
[07:31] <smb> cooloney, But quickly looking, I am not sure I see it. Where did you send this? cc me somewhere or our mailing list(s)
[07:31] <cooloney> we will got oops with CFQ but not with deadline
[07:31] <smb> cooloney, Well sure that is maybe not the ideal fairness but should not yet bet fatal. 
[07:32] <cooloney> smb: yeah, not fatal.
[07:32] <smb> Means somehow deadline still does not cause a latency of more that 10s while cfq des
[07:32] <smb> does
[07:32] <cooloney> smb: i sent to c-k-t
[07:32] <smb> cooloney, Ohhh
[07:32] <smb> You mean last week ...
[07:32] <cooloney> yeah,
[07:32] <smb> That one I did see. Thought it was something new
[07:32] <cooloney> it should be last friday
[07:33] <smb> Sorry, yeah, I saw that test. Surely I need to check on the latency values on the data I got.
[07:33] <smb> But I have not yet done so
[07:34] <cooloney> smb: np, do you think i can put cking's evalution report in LP bug?
[07:35] <smb> cooloney, I would maybe wait till we get some time to talk to him. I think for how it looks, test data may concentrate on the wrong details. This was mainly looking at the trhoughput
[07:36] <smb> But the gelt problem seems rather that the latency goes quite high
[07:36] <smb> This sounds a bit too bad for something called fair scheduler. I wonder whether it is something basic or really a bug in the code
[07:37] <smb> If we add data, we should put up both views
[07:37] <cooloney> smb: yeah, my friend in taobao.com said they originally used CFQ by default, but got some time out writing issue in their system
[07:38] <cooloney> then they applied some patches from google to add deadline features in CFQ, 
[07:38] <cooloney> so i'm looking for those patches
[07:38] <cooloney> but not sure it's the same issue
[07:40] <smb> Right, initially I thought that it might just be the emulated disk controller but if there is something really wrong with cfq and it is possible to get it so badly behaving that there seems to be no progress, this sounds like a real problem with cfq
[07:41] <smb> I think it would be interesting to have several io tasks in parallel and see how much the latency and runtimes differ...
[07:41] <ppisati> moin
[07:42] <smb> Since throughput seems not too bad, it looks a bit like that is done in chunks that potentially are long times apart
[07:42] <smb> ppisati, morning
[07:43] <cooloney> ppisati: morning, man
[07:44] <cooloney> smb: for parallel tasks, I just run bonnie++ 3 times in background
[07:46] <smb> cooloney, Right, now you only need to gather the data for that. Meaning probably a) how long do those tasks run, b) what is the throughput and c) how much latency each task sees on those tests...
[07:47] <smb> And at least while looking at the latency one needs to be careful as bonnie does change the scale
[07:50] <cooloney> smb: ok, i will test it again, my computer will be quite slow when testing this. -:<
[07:53] <smb> cooloney, Hold on just a bit. I could do it as well on a different machine. Or it might be that cking has the data already but jut not yet put into graphs
[07:54] <cooloney> smb: ok, np, actually, i have a server machine, which was occupied by my wife.
[07:54] <smb> cooloney, And you really think _was_? ;)
[07:56] <cooloney> smb: it't not very powerful actually, and any new items for lxc or virt stuff you think i need to take care of?
[07:56] <cooloney> smb: i found there is not much work for lxc,
[07:59] <smb> cooloney, Not directly, but making sure at least one of us knows all the parts on the kernel side to make it work (or to adjust if needed). And verify the test cases Serge has (are they covering enough, is something missed)
[08:00] <smb> Especially interesting should be how they try to get the environment as secure as possible. 
[08:09] <cooloney> smb: got it. thx
[08:10]  * apw looks out on a new week
[08:17] <smb> apw, nothing to see. It is just preparing to lash out 
[08:20] <cooloney> apw: morning
[08:20] <apw>  moin
[08:20] <smb> cooloney, So cking would be helping to do some testing later on. He got lots of kit to let it run on
[08:21] <cooloney> smb: cool, save my poor computer.
[09:39]  * ppisati notes 3.5rcX redefines the concept of "f*cked up" for omap3
[10:06] <cooloney> ppisati: what's the "f*cked up" crap in 3.5-rc for omap3?
[10:16] <ppisati> cooloney: it doesn't survive 2 boots in a row
[10:16] <ppisati> cooloney: secondo time the fs is badly corrupted
[12:17] <tgardner> henrix, did you see the email on the kteam list about the hp infrared RC6 remote regression ?
[12:18] <henrix> tgardner: checking...
[12:18] <henrix> tgardner: ah, ok. will reply in a minute
[12:19] <henrix> tgardner: i'm actually looking at a similar bug with same kernel
[12:19] <tgardner> henrix, ack
[14:47]  * ogasawara back in 20
[14:58] <ppisati> brb
[15:10] <sisar> i want to file a bug about touchpad, i should file it under "ACPI" or "Drivers" ? (https://bugzilla.kernel.org/enter_bug.cgi)
[15:36] <rtg> ogasawara, herton, apw: I need to reboot gomeisa to clean up some sbuild carnage.
[15:36] <herton> rtg, ack
[15:36] <ogasawara> rtg: gimme 2min to copy some build logs off
[15:36] <rtg> ogasawara, ack
[15:37] <ogasawara> rtg: ok, reboot whenever you're ready
[15:48] <rtg> herton, ownership on gomeisa seems to have gotten totally scrogged when I installed sbuild. its gonna take awhile to restore ownership settings I think
[15:48] <herton> rtg, yep heard that, I probably will go to tangerine for now too
[15:53] <apw> rtg, ack
[16:04]  * ppisati -> gym, back in a bit
[16:06]  * herton -> lunch
[17:23] <bambee> hi
[17:26] <ogasawara> bambee: hi, thanks for joining the channel.  you mentioned you were interested in getting involved and I suggested bug triage is a nice place to start as it gets you familiar with Launchpad, how our bugs are handled, and our typical work flows in general.
[17:27] <ogasawara> bambee: if this is something you'd like to start with I'd actually point you to jsalisbury and he can help you get started.
[17:27] <jsalisbury> bambee, o/
[17:28] <bambee> jsalisbury: hi 
[17:28] <jsalisbury> bambee, if you are interested in triage there is a few good wiki pages that is good to review:
[17:28] <jsalisbury> bambee, https://wiki.ubuntu.com/Bugs/HowToTriage
[17:29] <bambee> I would be interested in kernel/testing and debugging, I think or debugging+triaging
[17:29] <jsalisbury> bambee, there is allot of info there.
[17:29] <jsalisbury> bambee, we can always use help testing :-D
[17:30] <jsalisbury> bambee, and debugging/triaging
[17:30] <bambee> oh
[17:32] <jsalisbury> bambee, the best way to get started is to take a look at some of the wiki docs.  Then go through the process of triaging a new bug, which I can help you with.  And if you find a bug with similar hardware that you have, testing for those types of bugs really help.
[17:32]  * bambee is reading the wiki docs
[17:34] <bambee> ok it's noted, thanks for your explanations ;)
[17:35] <jsalisbury> bambee, sure np.  just let me know if you run into anything you have questions on.
[17:39] <bambee> for a beginning, you're right, I think that's probably better to start with triaging and testing (to be familiar with launchpad and your development process). Later I think I would like to help with development, and bugs fixing (this is a task reserved for guru, probably).
[19:53] <bdmurray> apw: any news on bug 882147?
[19:53] <ubot2> Launchpad bug 882147 in linux "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147
[21:02]  * rtg -> eod
[21:30] <henrix> jsalisbury: ping
[21:30] <jsalisbury> henrix, pong
[21:30] <henrix> jsalisbury: regarding bug #1014800
[21:30] <ubot2> Launchpad bug 1014800 in linux "infrared remote doesnt work anymore (3.2.0-26)" [Medium,Confirmed] https://launchpad.net/bugs/1014800
[21:30] <henrix> jsalisbury: mind if i step in? i believe i know the issue, so i've built a test kernel
[21:31] <jsalisbury> henrix, absolutely :-D  Thanks for the help!
[21:31] <henrix> jsalisbury: thanks. its related with a patch i submitted
[21:31] <jsalisbury> henrix, ok, thanks
[21:31] <henrix> jsalisbury: so, i'll just "readjust" the patch and it should fix it
[21:32] <jsalisbury> henrix, good stuff
[21:32] <henrix> jsalisbury: ;)