| --- | Log | opened Mon May 05 00:00:26 2008 |
| 00:53 | -!- | gonner [helopannda@123-243-151-148.static.tpgi.com.au] has joined #uml |
| 00:54 | -!- | gonner [helopannda@123-243-151-148.static.tpgi.com.au] has left #uml [] |
| 04:11 | -!- | kos_tom [~thomas@humanoidz.org] has quit [Remote host closed the connection] |
| 06:13 | -!- | kos_tom [~thomas@humanoidz.org] has joined #uml |
| 07:27 | -!- | krau [~cktakahas@189.70.28.236] has quit [Quit: Varei!!!] |
| 07:54 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 08:15 | -!- | krau [~cktakahas@200.184.118.132] has quit [Remote host closed the connection] |
| 08:21 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 08:52 | -!- | dang [~dang@aa-redwall.ghs.com] has joined #uml |
| 08:53 | -!- | dang [~dang@aa-redwall.ghs.com] has left #uml [] |
| 08:53 | -!- | dang [~dang@aa-redwall.ghs.com] has joined #uml |
| 09:11 | -!- | balbir [~balbir@122.167.194.224] has quit [Ping timeout: 480 seconds] |
| 09:22 | -!- | balbir [~balbir@122.167.194.224] has joined #uml |
| 09:38 | -!- | balbir [~balbir@122.167.194.224] has quit [Ping timeout: 480 seconds] |
| 09:49 | -!- | balbir [~balbir@122.167.194.224] has joined #uml |
| 10:22 | -!- | jdike [~jdike@pool-72-93-84-45.bstnma.fios.verizon.net] has joined #uml |
| 10:22 | <jdike> | Hi guys |
| 10:32 | -!- | weaselTM [weasel@weasel.chair.oftc.net] has joined #uml |
| 11:12 | -!- | peterz [~peterz@f237116.upc-f.chello.nl] has quit [Ping timeout: 480 seconds] |
| 11:13 | -!- | peterz [~peterz@f237116.upc-f.chello.nl] has joined #uml |
| 12:02 | -!- | ram [~ram@pool-71-245-96-80.nycmny.fios.verizon.net] has quit [Ping timeout: 480 seconds] |
| 12:15 | <mike_m> | hi jdike |
| 12:16 | <mike_m> | will skas4 support PTRACE_LDT eventually? |
| 12:16 | <mike_m> | or is the plan to do that using tt mechanisms? |
| 12:18 | <jdike> | there's no need for PTRACE_LDT in skas4 |
| 12:19 | <jdike> | skas4 has a mechanism for running an arbitrary system call in a different address space |
| 12:19 | <mike_m> | ah, i see |
| 12:21 | * | mike_m tries to figure out how... |
| 12:23 | <jdike> | new_mm() gives you the new address space |
| 12:23 | <jdike> | use skas0 mechanisms to map stubs into that address space |
| 12:24 | <jdike> | when you need to change a mapping or run modify_ldt, switch_mm switches to a stub in that address space which does the work |
| 12:24 | <jdike> | and switch_mm()s back |
| 12:33 | <mike_m> | so the process remains the same, but the address space changes... |
| 12:33 | <jdike> | yeah |
| 12:36 | <mike_m> | hmm. so you'll need to have a small bit of memory in the guest kernel's address space, with the code in there that you want to run |
| 12:37 | <mike_m> | just like tt |
| 12:37 | <jdike> | the guest process |
| 12:37 | <jdike> | but yes |
| 12:37 | <jdike> | that's the aforementioned stub |
| 12:37 | <jdike> | one page of kernel code, one page for data |
| 12:38 | <mike_m> | a process running in a guest will be able to see that too? |
| 12:38 | <jdike> | it can see the pages |
| 12:38 | <jdike> | they look like vdsos |
| 12:38 | <mike_m> | but not necessarily modify them |
| 12:39 | <jdike> | it can't modify the code, for obvious reasons |
| 12:39 | <jdike> | the data page has to be writeable, but that doesn't matter |
| 12:39 | <mike_m> | because the guess won't run at a time when modifying that data can matter... |
| 12:40 | <jdike> | right |
| 12:40 | <jdike> | the data is put there and used before the process has another chance to run |
| 12:40 | * | mike_m wonders if UML will support SMP |
| 12:41 | <jdike> | so any changes the process makes to that page are blown away (or ignored) |
| 12:41 | <jdike> | it will |
| 12:41 | <jdike> | it's easy with skas4, somewhat nightmarish for skas0 |
| 12:41 | <mike_m> | so you'll have to stop the second "processor" when doing that |
| 12:41 | <jdike> | yes |
| 12:42 | <mike_m> | i should probably explain my interest... |
| 12:42 | <mike_m> | i'm trying to write something like UML |
| 12:42 | <mike_m> | using a linux host |
| 12:42 | <mike_m> | and a different OS as guest |
| 12:43 | <mike_m> | i've got something working using SKAS3 |
| 12:43 | <mike_m> | and will move to SKAS4 when it's available, i guess |
| 12:44 | <mike_m> | so if you're looking for another tester for this interface, I'm willing to help |
| 12:44 | <jdike> | I've put out patches |
| 12:45 | <mike_m> | the one against 2.6.24? (http://marc.info/?l=user-mode-linux-user&m=120223044125132&q=raw) |
| 12:46 | <mike_m> | or is there something newer I have missed? |
| 12:47 | <jdike> | that's it |
| 12:47 | <mike_m> | i had a go applying that to 2.4.25 |
| 12:47 | <jdike> | heh |
| 12:47 | <mike_m> | or the current git tree |
| 12:47 | <jdike> | I haven't dumped it into 2.6.25 yet |
| 12:47 | <mike_m> | the ptrace 32/64 stuff is all merged |
| 12:48 | <mike_m> | i tried to merge it as best I could |
| 12:48 | <mike_m> | got something that compiled |
| 12:48 | <mike_m> | but wasn't game to boot it up :) |
| 12:48 | <jdike> | so you didn't even try? |
| 12:48 | <jdike> | wimp\ |
| 12:48 | <mike_m> | hehe :) |
| 12:49 | <mike_m> | well, i thought about getting out an old laptop to try it |
| 12:49 | <jdike> | it'll boot |
| 12:49 | <jdike> | assuming no egregious mistakes |
| 12:49 | <mike_m> | yeah, i hope i haven't screwed it up that much that it won't boot :) |
| 12:49 | <jdike> | the only way it'll kill your machine is if you actually try to use it |
| 12:49 | <mike_m> | but as soon as I try a switch_mm, all bets are likely off |
| 12:50 | <jdike> | if you got reasonably clean merging, I'd say there's a decent chance of it working |
| 12:50 | <jdike> | and the failure modes are more likely to be process segfaults than a dead box |
| 12:50 | <mike_m> | the stuff in arch/x86/kernel/ptrace.c wasn't so easy to merge |
| 12:51 | <mike_m> | i'm not entirely sure how to handle the 64/32 bit stuff |
| 12:51 | <mike_m> | and don't have an x86-64 box to try that side of the code |
| 12:51 | <jdike> | you can leave that out if you don't care about 32-bit guests on 64-bit hosts |
| 12:52 | <jdike> | which I guess you don't |
| 12:52 | <mike_m> | yeah, not yet |
| 12:52 | <jdike> | and you can't even build it into your kernel anyway |
| 12:52 | <mike_m> | i guess i should be brave and try boot it :) |
| 12:53 | <mike_m> | thanks for helping me understand how it works |
| 12:54 | <jdike> | np |
| 12:55 | -!- | ram [~ram@bi01p1.co.us.ibm.com] has joined #uml |
| 14:12 | -!- | krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!] |
| 14:17 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 14:22 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has quit [Quit: leaving] |
| 14:35 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has joined #uml |
| 14:35 | <bldewolf> | hey jdike, I found I had a 2.6.23 kernel still and booted it, and my UML machine ran at a bearable pace |
| 14:42 | -!- | krau [~cktakahas@200.184.118.132] has quit [Remote host closed the connection] |
| 14:45 | <bldewolf> | so it looks like the issue is between 2.6.23 and 2.6.24... |
| 14:48 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 14:50 | <jdike> | the host, right? |
| 14:50 | <bldewolf> | yeah |
| 14:51 | <jdike> | any config differences? |
| 14:51 | <bldewolf> | yeah, where can I paste a diff? |
| 14:52 | <jdike> | rafb.net |
| 14:53 | <bldewolf> | http://rafb.net/p/BfVMyE50.html |
| 14:55 | <jdike> | ummm |
| 14:55 | <jdike> | you went from a 32-bit kernel to a 64-bit one? |
| 14:58 | -!- | krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!] |
| 14:58 | <bldewolf> | no? |
| 14:59 | <jdike> | oh wait |
| 15:01 | <bldewolf> | a bunch of the X86 stuff moved to the bottom of the file, if that's what you're talking about. I noticed that too :) |
| 15:04 | <jdike> | I was looking at 64BIT and X86_64 before noticing they were commented out |
| 15:14 | -!- | hfb [~hfb@pool-71-118-254-245.lsanca.dsl-w.verizon.net] has joined #uml |
| 15:21 | <jdike> | how about sorting them, then diffing? |
| 15:21 | <jdike> | grep out the comments, then diff |
| 15:21 | <bldewolf> | alright |
| 15:21 | <jdike> | that'll expose the actual differences |
| 15:24 | <bldewolf> | http://rafb.net/p/ijn6sE35.html |
| 15:25 | <jdike> | that's a lot moer manageable |
| 15:25 | <jdike> | more |
| 15:27 | <jdike> | nothing jumps out |
| 15:27 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 15:27 | <bldewolf> | fiddlesticks |
| 15:27 | <jdike> | how much effort to you feel like spending to chase this down? |
| 15:28 | <jdike> | first thing I'd do is move the config changes from one version to the other to see if the performance problem moves with them |
| 15:28 | <jdike> | if so, then I'd bisect the changes to see what makes the difference |
| 15:29 | <jdike> | if not, I'd bisect the kernel between .23 and .24 to see where the performance dropped |
| 15:31 | <jdike> | -CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y |
| 15:31 | <jdike> | +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y |
| 15:31 | <jdike> | that's one of the few clear changes |
| 15:31 | <jdike> | no idea what it means (least of all for UML) though |
| 15:55 | <bldewolf> | well, it chooses the default cpu governor, but I've ended up leaving it running full tilt always so I figured I'd bump it back to performance |
| 15:58 | <bldewolf> | I've tried to get my 2.6.24 config back in line with my 2.6.23, but I can't find some options, like SLABINFO...I'll give it a try when I get back from lunch |
| 15:58 | <jdike> | SLABINFO I think is harmless |
| 15:58 | <jdike> | I bet that just makes /proc/slabinfo available |
| 17:26 | -!- | dang [~dang@aa-redwall.ghs.com] has quit [Quit: Leaving.] |
| 17:30 | <bldewolf> | time to reboot and see if it's any better |
| 17:30 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has quit [Quit: leaving] |
| 17:34 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has joined #uml |
| 17:35 | <bldewolf> | no improvement :( |
| 17:35 | <bldewolf> | what were the other suggestions? |
| 17:53 | -!- | kos_tom [~thomas@humanoidz.org] has quit [Remote host closed the connection] |
| 18:01 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has quit [Quit: leaving] |
| 18:09 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has joined #uml |
| 18:11 | <bldewolf> | Well, I went back to a 2.6.23 kernel, and everything's happy now |
| 18:12 | -!- | ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds] |
| 18:14 | <bldewolf> | What kind of kernel hacking would I have to go through to figure out what exactly is causing the problem? |
| 18:16 | <mike_m> | git bisect would probably work |
| 18:16 | <mike_m> | assuming you can use the same configuration... |
| 18:17 | <bldewolf> | makes me wonder if I could recreate this problem in a UML client under a 2.6.24 UML client... :) |
| 18:17 | <mike_m> | hehe :) |
| 18:17 | <mike_m> | well, bisect will find the problem without too much thinking |
| 18:17 | <mike_m> | it might take some time though |
| 18:19 | <mike_m> | it will take around log2(N) rebuilds of the kernel |
| 18:19 | <bldewolf> | yeah I should probably get back to work... |
| 18:19 | <bldewolf> | woo slow mondays! |
| 18:19 | <mike_m> | where N is the number of commits between your good and bad point |
| 18:20 | <mike_m> | it was a public holiday here :) |
| 18:21 | <bldewolf> | for cinco de mayo? |
| 18:21 | <bldewolf> | I'm guessing not, but you never know... |
| 18:23 | <mike_m> | for the early may long weekend... |
| 18:24 | -!- | krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!] |
| 18:33 | <bldewolf> | you get an early may long weekend for fun? I think I need to move! |
| 18:38 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 18:45 | -!- | krau [~cktakahas@200.184.118.132] has quit [Remote host closed the connection] |
| 18:46 | <mike_m> | yep, and a late one too :) |
| 18:48 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 19:08 | <jdike> | the next suggestion is to bisect between .23 and .24 |
| 19:53 | -!- | jdike [~jdike@pool-72-93-84-45.bstnma.fios.verizon.net] has quit [Quit: Leaving] |
| 20:09 | -!- | hfb [~hfb@pool-71-118-254-245.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving] |
| 20:38 | -!- | bldewolf [~bldewolf@woof.iitsystems.csupomona.edu] has quit [Quit: leaving] |
| 23:59 | -!- | VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs] |
| 23:59 | -!- | VS_ChanLog [~stats@ns.theshore.net] has joined #uml |
| --- | Log | closed Tue May 06 00:00:03 2008 |
![[FSF Associate Member]](/assets/fsf.png){kind=small}
