| neuro_sys | mjg59: when using this bios call, r.flags should contain the correct values? http://www.ctyme.com/intr/rb-1755.htm | 00:35 |
|---|---|---|
| neuro_sys | with libx86. | 00:35 |
| mjg59 | neuro_sys: No | 00:35 |
| mjg59 | neuro_sys: libx86 is in no way guaranteed to actually let you make arbitrary BISO calls | 00:36 |
| mjg59 | The only things you should expect to work are graphics calls | 00:36 |
| neuro_sys | does it emulate or something? Actually I need to have a look at vm86 first I guess. | 00:36 |
| mjg59 | The rest of the BIOS isn't hooked up at all | 00:36 |
| neuro_sys | okay | 00:36 |
| xiackok | ok there is kernel system calls | 00:39 |
| lifeless | apw: I mailed the kernel list; I presume it went to moderation | 05:34 |
| lifeless | apw: I also forgot to say that I'm not subscribed ... so I won't see replies | 05:34 |
| smb | lifeless, I forwarded you my reply which only went to the list accidentally | 06:59 |
| lifeless | smb: thanks! | 07:00 |
| smb | lifeless, Actually a request based mapping might be more desirable than a merge function for bios. Cause for the latter you would have to find out the common max of all mirrors if I understood correctly. Which sounds much more complicated. While for rq mapping the elevators just should be able to merge. | 07:11 |
| smb | After all multipath had the same problem there. | 07:11 |
| lifeless | smb: common max? | 07:14 |
| lifeless | smb: is request a larger unit of work ? | 07:14 |
| smb | I mean the maximum size of a bio all the mirror paths/drives can handle. Yes, request is a set of bios | 07:15 |
| smb | Normally for a request queue the elevators can merge bios into an existing request if it is adjacent. But for the bio based mapping there is no such thing | 07:17 |
| lifeless | smb: I've replied; I appreciate the feedback; I guess I think further fiddling isn't likely to have much impact - the kernel is merging the bios on the targets post mapping | 07:17 |
| lifeless | smb: hmm, they are definitely being merged | 07:17 |
| lifeless | Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util | 07:18 |
| lifeless | sda 3854.60 0.80 270.00 5.40 16498.40 21.60 119.97 0.14 0.50 0.43 4.07 0.43 11.80 | 07:18 |
| lifeless | 3854 -> 270 | 07:18 |
| smb | Did you see that? Cause iirc going through the device-mapper bio mapping was past the queues and so no merging was done | 07:18 |
| lifeless | dm-1 0.00 0.00 4124.60 6.20 16498.40 21.60 8.00 1.34 0.33 0.32 3.23 0.03 11.80 | 07:19 |
| lifeless | is the raid1 device | 07:19 |
| lifeless | so it got 4K reads, which all got mapped, then 3.8K were merged into the other 270 | 07:20 |
| lifeless | bbiab, cooking dinner | 07:22 |
| smb | Hm seems like. Yeah. | 07:22 |
| smb | At least dm does no queue here, so merging is not done before sending it down a path | 07:23 |
| lifeless | smb: its pretty efficient on sequential IO: | 07:34 |
| lifeless | sda 25616.80 0.00 1816.60 1.80 109734.40 6.40 120.70 1.06 0.59 0.57 17.78 0.41 74.20 | 07:34 |
| lifeless | dm-1 0.00 0.00 27368.00 1.80 109472.00 6.40 8.00 14.99 0.55 0.55 17.78 0.03 74.00 | 07:34 |
| lifeless | 100MB/sec out of the drive | 07:34 |
| smb | Well yes, just thought in the past the bios would just get passed on behind a dm device. But it could have changed. Your sda is also only used for that raid, right? | 07:35 |
| lifeless | dd from the drive gets: | 07:35 |
| lifeless | 131072000 bytes (131 MB) copied, 1.07633 s, 122 MB/s | 07:35 |
| lifeless | yeah, its a raid 1+0 ICH10R | 07:36 |
| lifeless | so sda and sdb are raid1 together | 07:36 |
| lifeless | sdc and sdd are raid1 together | 07:36 |
| lifeless | and dm1 and dm3 are striped together into dm5 | 07:36 |
| lifeless | dm5 is what gets partitioned etc | 07:36 |
| lifeless | so without the patch, sequential IO + interactive IO is a bit poor | 07:38 |
| smb | Ok, so merging at least happens on the backing devices. Just not for the mirror target which then can pass bios to both sides without caring whether they are mergeable | 07:38 |
| lifeless | with it deals better | 07:38 |
| lifeless | smb: yeah, thats my observation | 07:38 |
| smb | Isn't the current code doing no read balance at all? | 07:38 |
| lifeless | correct | 07:39 |
| smb | Ok, so I read the old one correctly. :) | 07:39 |
| lifeless | which is why sequential IO + interactive IO is bad :) | 07:39 |
| lifeless | because you die from seeks | 07:39 |
| smb | Right, it works around not merging but misses the oportunity of using a second source | 07:39 |
| lifeless | my patch avoids that some of the time - when the IO distance is reasonable | 07:40 |
| lifeless | smb: I did try two sources for sequential IO | 07:40 |
| lifeless | smb: if you get it wrong, its way worse ;) | 07:40 |
| smb | I can believe that | 07:40 |
| smb | Would basically break up the chance for merging | 07:40 |
| lifeless | exactly | 07:41 |
| lifeless | so I think the heuristic I'm add is valuable even if we add a merge method | 07:41 |
| lifeless | or request handling | 07:41 |
| lifeless | IMBW :) | 07:41 |
| smb | Just my gut feeling is that, when asking upstream, they will point at how multipath went to request based mapping and that avoids the need for heuristics | 07:42 |
| smb | In the simplest form (before having the rq_map) they just used the same path x times and then switched in a round-robin balancer | 07:44 |
| smb | Was not bad but had exactly the same issue of being dumb about possible merges | 07:44 |
| smb | lifeless, But that is my personal feeling. You certainly can get more accurate feedback from dm-devel. My knowledge there has become a bit rusty from not looking all the time | 07:48 |
| lifeless | smb: ok, thats good to know | 07:57 |
| lifeless | smb: I think I'll wait for them to say that; if multipath knew that writes had to go to all devices, we could just have multipath layered in the mix | 07:58 |
| smb | lifeless, Yeah, though for multipath it is actually the other way. Writes do go to all devices as it is really only one. Just there are multiple way to reach. The problem there is more that on the other end there may be a stupid handler or transport is more efficient in bulk | 08:01 |
| lifeless | right, I meant 'transmit on all paths | 08:02 |
| lifeless | ' | 08:02 |
| lifeless | because raid1 is 'write to all read from one + a bitmap for region synchronisation' | 08:02 |
| smb | Right, different use cases. For mpath transmit to all paths is futile or stupid so it is not intended for that. But there is one patch in the past which introduces the rq_map stuff in the past and it did not look too terrible. It might be a source to look at. | 08:04 |
| smb | f40c67f0f7e2767f80f7cbcbc1ab86c4113c202e | 08:05 |
| apw | ppisati: have you created bugs for the two new CVEs yet? i would like to test some scripting on them if not | 08:57 |
| apw | (ie. i want to make them) | 08:57 |
| apw | but i don't trust launchpad to find them | 08:57 |
| ppisati | apw: which one? | 09:03 |
| ppisati | ah | 09:03 |
| apw | 2011-1770 | 09:03 |
| ppisati | nope | 09:04 |
| apw | and 2011-2484 | 09:04 |
| ppisati | nope | 09:04 |
| apw | cool, i'll sort them out then thanks | 09:04 |
| ppisati | din't notiche them (yet) | 09:04 |
| apw | ppisati: has anyone pointed you at the new page with the open CVEs on it, the bug view: http://people.canonical.com/~kernel/reports/kernel-cves.html | 09:59 |
| apw | this is the first proto-type of an incoming queue for us, once kees starts making the bugs | 10:01 |
| smb | Yet another one... But I guess that one goes with the bugs and will get us rid of supertracker | 10:02 |
| apw | smb, yeah its about getting rid of the tracker, and about the fack stupid launchpad searches do NOT work | 10:02 |
| apw | ppisati, you must teach me how you find a CVE bug in launchpad. even when i have just opened one and i know its number i cannot find it using traditional searches ... it makes NO sense | 10:03 |
| apw | smb, can you find the bug for CVE-2011-1070 ? | 10:10 |
| ubot2 | apw: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1070) | 10:10 |
| apw | bug #806375 | 10:10 |
| ubot2 | Launchpad bug 806375 in linux-ti-omap4 "CVE-2011-1770" [Undecided,Invalid] https://launchpad.net/bugs/806375 | 10:11 |
| apw | that bug is New in linux but i cannot get a search on linux bugs to find it | 10:11 |
| smb | hm | 10:14 |
| apw | i am being told its "the hyphens" | 10:14 |
| smb | So you are trying to search the number and they fail ... bah | 10:15 |
| smb | how useful is that... | 10:16 |
| smb | No don't know how to do it. Stripping of the CVE part and only using numbers gives you completely unrelated bugs | 10:18 |
| aroth | hi, i found the following kernel bug: http://paste.ubuntu.com/638832/ | 11:10 |
| aroth | how should i proceed? | 11:10 |
| bliss | that's a fairly short list of CVE bugs | 11:22 |
| bliss | not complete, i suppose? | 11:23 |
| bliss | i'd expect CVE-2011-2497 and CVE-2011-2213 to be unfixed so far | 11:23 |
| ubot2 | bliss: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2497) | 11:23 |
| ubot2 | bliss: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2213) | 11:23 |
| bliss | very helpful ubot2, thanks :p | 11:24 |
| apw | bliss, nope its likely incomplete currently | 12:32 |
| bliss | i'll have to give you guys some more to work on ;-) | 12:33 |
| bliss | can't have the ubuntu kernel team getting bored | 12:33 |
| bliss | off to work, later | 12:35 |
| neuro_sys | jeroen tel vs. piper fawn | 13:08 |
| * apw wanders out for a bit, some fresh air is required | 13:34 | |
| === _LibertyZero is now known as LibertyZero | ||
| * apw notes it is windy out | 14:31 | |
| * tgardner steps out for an appt. back in a couple hours | 14:32 | |
| === tgardner is now known as tgardner-afk | ||
| brendand | bjf - is https://bugs.launchpad.net/ubuntu/+source/linux/+bug/802554 really still being verified? i thought i saw an email from sconklin last week saying it could be tested? | 14:44 |
| ubot2 | Ubuntu bug 802554 in linux "linux: 2.6.32-33.69 -proposed tracker" [Medium,In progress] | 14:44 |
| bjf | herton, ^ | 14:49 |
| === bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - July-12 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| herton | brendand: yes, everything on lucid seems verified, I'll check and set it to fix released | 14:50 |
| brendand | herton - thanks, | 14:52 |
| bjf | apw, irc meeting scripts updated and pushed | 14:52 |
| apw | bjf were we missing a bit ? | 14:52 |
| bjf | apw, yup, fixed | 14:53 |
| apw | other than the little hickup everything else went well, we found all the reports in the end and added to the README | 14:53 |
| herton | brendand: done, you can assign yourself on the bug and start working etc. | 14:54 |
| bjf | apw, all pages have been updated and email sent, i think it's a wrap | 14:55 |
| apw | bjf, thanks for that | 14:55 |
| bjf | np | 14:55 |
| apw | everytime you are away we get closer to it working :) | 14:55 |
| bjf | apw, as "punishment" for getting my upload rights, it looks like I now get to do "patch pilot", i've been assigned dates | 14:58 |
| apw | bjf, indeed so :/ | 14:58 |
| apw | bjf, we ussually use that to review the incomng bugs in linux with patches | 14:58 |
| bjf | apw, ack, that was my plan | 14:59 |
| bjf | apw, i believe that is what we agreed to in dallas | 14:59 |
| apw | bjf, indeed so, and its actually been pretty good at finding real patches to apply | 14:59 |
| === tgardner-afk is now known as tgardner | ||
| herton | bjf: do you know/remember if someone from kernel team must verify tracking bugs, or can we set verification -> fix released for bug 795153 | 17:35 |
| ubot2 | Launchpad bug 795153 in linux-mvl-dove "linux-mvl-dove: 2.6.32-417.34 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/795153 | 17:35 |
| herton | I mean, verify *arm* tracking bugs | 17:36 |
| * tgardner --> lunch | 18:06 | |
| cking | when tgardner goes to lunch it reminds me I should be finishing up for the day | 18:07 |
| apw | bjf, could you remind me where the documentaiton on how to upload one of these puppies is? i need the switch to make it use lucid | 18:08 |
| bjf | https://wiki.ubuntu.com/Kernel/StableReleaseCadence | 18:09 |
| bjf | apw, ^ bottom of the page | 18:09 |
| === Quintasan_ is now known as Quintasan | ||
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!