1164412917 Q * dna_ Quit: Verlassend 1164413003 Q * Johnnie Remote host closed the connection 1164413091 M * Wonka woohoo 1164413105 M * Wonka first time since two weeks or something that this vserver host didn't hang 1164413120 M * daniel_hozac Bertl: the bucket is full all the time, and the user/sys/hold_ticks are all 0. 1164413142 M * Bertl okay, how? 1164413145 J * Johnnie ~jdlewis@jdlewis.org 1164413150 M * daniel_hozac that i have no idea. 1164413188 M * Bertl the only case I could imagine is when the task is running with real-time priority ... 1164413213 M * Bertl could you enable the debug logging and carefully look at the scheduler decisions? 1164413225 M * Bertl (especially the scheduling monitor should help) 1164413461 M * daniel_hozac looks like i don't have the monitor enabled in my config, i'll have to enable that first. 1164413475 M * daniel_hozac (this is on 2.1.1+patches btw) 1164413528 M * Bertl hmm .. I have a suspicion ... 1164413658 M * Bertl daniel_hozac: what arch is that? 1164413661 M * daniel_hozac x86. 1164413668 M * daniel_hozac i686 to be exact. 1164413681 M * Bertl SMP? 1164413713 M * daniel_hozac it's an SMP capable kernel, but a UP box. 1164413720 M * Bertl apic? 1164413745 M * daniel_hozac looks like, any definite way to check? 1164413752 M * Bertl /proc/interrupts 1164413778 M * daniel_hozac no, XT-PIC. 1164413801 M * daniel_hozac (or is that a yes?) 1164413808 M * Bertl bingo! 1164413820 M * Bertl -· scheduler_tick() 1164413820 M * Bertl ¦-· account_process_time() 1164413820 M * Bertl ¦ '-· timer_interrupt() 1164413820 M * Bertl ¦ ¦-· cbe_system_reset_exception() 1164413820 M * Bertl ¦ ¦-· do_IRQ() 1164413861 M * Bertl we switch to xid=0 for do_IRQ 1164413874 M * Bertl so the scheduler has no information on the context 1164413882 M * daniel_hozac ah! 1164413904 M * Bertl all my systems have the apic enabled 1164413911 M * Bertl even QEMU runs with apic ... 1164413922 M * Bertl the apic part is not affected :) 1164413929 M * daniel_hozac ah, ok. 1164413938 M * daniel_hozac so that explains it, i guess. 1164413944 M * daniel_hozac time to move to in_interrupt()= 1164413947 M * daniel_hozac s/=/?/ 1164413975 M * daniel_hozac or is there a much easier way to fix it? :) 1164414076 M * Bertl well, we could ahck around it, but I guess that's a hint to switch to in_interrupt() 1164414108 M * Bertl but I'd need some test support for that (a special kind of tests, actually) or we have to go through the code one by one 1164414132 M * daniel_hozac oh? 1164414188 M * Bertl the problem is, in_interrupt() is not without overhead 1164414204 M * Bertl so I'd prefer to make that check conditional at compiletime 1164414219 M * Bertl i.e. have the vx_check() use a special flag for that 1164414241 M * Bertl but to do so, we need to identify the vx_checks which can happen from inside an irq 1164414269 M * Bertl so, I'd suggest to do a simple trigger patch for that 1164414298 M * Bertl i.e. a code fragment, which checks if in_interrupt() is present, and then warns once 1164414328 M * Bertl this way we should identify them quite easily 1164414378 M * Bertl what do you think? 1164414418 M * daniel_hozac how much overhead is in_interrupt? 1164414445 M * Bertl it's hard to tell, have to investigate 1164414446 M * daniel_hozac i'm not sure i understand what the trigger patch would do. 1164414457 M * daniel_hozac warn once per path that calls vx_check in_interrupt()? 1164414486 M * Bertl yep 1164414505 J * shedi ~siggi@inferno.lhi.is 1164414565 M * daniel_hozac so the once is the key then... maybe just store the top 3 from the call stack (if it is that deep) in some list we check against? 1164414581 M * daniel_hozac this would be a debug patch, right? 1164414656 M * daniel_hozac AFAICT, in_interrupt should just be something like 3 ops on x86. 1164414668 M * Bertl #define vx_check(c,m) ({ WARN_ON_ONCE(in_interrupt()); __vx_check(vx_current_xid(),c,m); }) 1164414674 M * Bertl that should do it 1164414687 M * daniel_hozac WARN_ON_ONCE exists already? 1164414694 M * Bertl yup 1164414697 M * daniel_hozac wow, nice. 1164414728 M * Bertl it's quite simple ... 1164414748 M * Bertl have been toying with the idea to extend that to some 'time'based approach 1164414756 M * Bertl i.e. make that ONCE a minute or so 1164414767 M * daniel_hozac ah, a static variable per usage. 1164414816 M * daniel_hozac yeah, sounds good. 1164414840 M * daniel_hozac although i'm not sure that's really necessary. 1164414897 M * Bertl #ifndef _LINUX_SCHED_H 1164414897 M * Bertl #include 1164414897 M * Bertl #include 1164414897 M * Bertl #endif 1164414901 M * Bertl this helps too :) 1164414946 M * Bertl we will have to handle that somehow in a patch 1164414964 M * daniel_hozac handle what? 1164414985 M * Bertl in_interrupt() needs sched.h, which includes vs_base 1164414999 M * daniel_hozac ah, recursive includes. 1164415003 M * daniel_hozac i love those. 1164415015 M * Bertl yes, but that's getting much better in 2.6.19 1164415036 M * Bertl argh, implicit declaration of function `in_interrupt' 1164415038 M * daniel_hozac so why isn't vs_base.h included from sched.h anymore? 1164415055 M * daniel_hozac or did you change that in -t3? 1164415104 M * Bertl hardirq is it now ... hmm ... what about soft irqs, btw? 1164415131 M * daniel_hozac ah, right... 1164415142 M * daniel_hozac we only want hardirqs, no? 1164415146 M * Bertl ah, no, irq_count() handles both, *phew* 1164415163 M * Bertl no, we actually want all irq contexts 1164415177 M * Bertl but that's not a problem we can select that 1164415182 M * daniel_hozac yeah. 1164415526 M * Bertl trying now .. 1164415579 M * Bertl nah, we have to move the vx_check() after hardirq 1164416050 M * Bertl I really love shed.h :/ 1164416057 M * Bertl *sched 1164416095 M * daniel_hozac hehe 1164416161 M * DavidS a freudian slip ;) g'night everyone! 1164416171 Q * DavidS Quit: Leaving. 1164416195 M * doener was sched.h that monstrous include-the-kitchen-sink-and-even-the-sewers header? 1164416201 M * daniel_hozac yes. 1164416993 J * Night-Fire ~davidb@251.034.dsl.brs.iprimus.net.au 1164417004 M * Bertl welcome Night-Fire! 1164417008 M * Night-Fire how can i run a fedora core 4 vserver on a debian box 1164417012 M * Night-Fire thanks Bertl 1164417045 M * Night-Fire because im trying to install plesk but the sarge vserer im using isnt working at all 1164417050 M * Night-Fire just wont install plesk 1164417063 M * Night-Fire how can i install fedora as a vserver 1164417070 M * Bertl well, I'd call that attitude :) 1164417087 M * Night-Fire what do you mean Bertl? 1164417101 M * Bertl that debian refuses to run plesk :) 1164417128 M * Bertl well, your hsot system is debian too, right? 1164417132 M * Night-Fire yeap 1164417135 M * Night-Fire etch 1164417144 M * Night-Fire i want to install a FC vserver though 1164417154 M * Night-Fire as i know FC will have no issues with it 1164417162 M * Bertl okay, I don't know the state of yum in debian, but that would be the best way 1164417211 M * Bertl if that doesn't work, you have some more options 1164417212 M * Night-Fire so install yum on the box, then what do i download via yum and what will the command line be? 1164417231 M * Bertl util-vserver knows how to use yum for fc* 1164417257 M * Night-Fire its already installed 1164417259 M * Bertl i.e. you can install then like a debian guest (see vserver - build --help) 1164417276 M * Bertl just use -m yum and the proper distro info 1164417306 M * Night-Fire would it be called FC4? 1164417319 M * Bertl if you want fc4, then yes 1164417326 M * Night-Fire yay 1164417331 M * Night-Fire let me try it out 1164417342 M * Bertl make sure you got recent tools though 1164417349 M * Night-Fire i have 1164417359 M * Night-Fire wait 1164417364 M * Night-Fire ill use yum for -m 1164417369 M * Night-Fire and for -d it will be fc4 1164417376 M * Night-Fire right? 1164417405 M * Bertl yep 1164417419 M * Night-Fire ok cool ill try it now 1164417431 M * Bertl don't forget to specify ip (--interface) and xid (--context) 1164417537 M * Bertl daniel_hozac, doener: could you figure for me how much 'unnecessary' dependancies it would add to move vs_memory.h into mm.h? 1164417677 M * Bertl in vserver - build --help you see that you can specify a bunch of config options at build time 1164417684 M * Bertl important ones are: 1164417689 M * Bertl --context ... the static context of the vserver 1164417700 M * Bertl (choose a number between 2 and 49151 there) 1164417707 M * Bertl --hostname 1164417722 M * Bertl --initstyle