IRC channel logs


back to list of logs

<gnucode>VedantT: good google summer of code!
<gnucode>youpi, I don't believe that I have my copyright assignment on file for the Hurd documentation...most of the stuff that I am sending is from the wiki, but I suppose that I should assign copyright to the FSF.
<ArneBab_>gnucode, anatoly: it’s so great to see that what I wrote is still useful! Thank you for keeping the Hurd going!
<damo22>i need to find more time to fix smp, it is proving to be quite difficult to fix as well
<azert>Hi damo22 , you are doing a great job for smp, I wonder how much slower it is now respect to no-smp on a single core
<azert>now like with your latest patch applied, if it is slower
<damo22>its still slower than uniprocessor mode
<damo22>im just refactoring now
<azert>if you were to give a factor?
<azert>Like 2x slower?
<azert>That’s great
<damo22>i may have a speedup with youpi's suggestion to simplify the CPU_NUMBER calls
<damo22>i think its broken because CPU_NUMBER is used in the spl code
<damo22>to get the curr_ipl per cpu
<AlmuHS>if i get time, i will try to help in smp. I'm firstly interested in fix the ext2fs problem, to progress in the boot
<AlmuHS>i think that fill the piece of code in pcb.c and others where there are TODO related with smp could help to improve it
<azert>AlmuHS: one good way to fix ext2fs perhaps is to compile a version that tie itself to one processor, and use that for the root fs. Then compile a version that goes full multiprocessing and run that on a mountpoint
<AlmuHS>axert: i need docs about how to make that
<azert>On Linux it would be sched_setaffinity , looks not implemented on the hurd
<azert>Maybe by implementing that
<azert>Is there anything equivalent in the Mach api?
<AlmuHS>i don't know, i have not enough experience in Hurd
<azert>Im looking into mach.texi
<azert>Yes there is
<azert>Processor set interface
<azert>Or thread_assign
<azert>If you have time you can try?
<AlmuHS>some years ago we tried to bound ext2fs to cpu0, but didn't worked
<azert>damo22 should know
<azert>He recently bounded everything to cpu0 kernel side and it worked
<azert>Should be possible to do it per application from userspace
<AlmuHS>damo22 and me are mates in smp project
<azert>I know
<AlmuHS>where is the task_assign that you referring?
<AlmuHS>in gnumach or in the ext2fs translator?
<almuhs>now connected from pc
<almuhs>ok, thread_assign definition is in thread.c , in gnumach
<almuhs> * thread_assign:
<almuhs> *
<almuhs> * Change processor set assignment.
<almuhs> * Caller must hold an extra reference to the thread (if this is
<almuhs> * called directly from the ipc interface, this is an operation
<almuhs> * in progress reference). Caller must hold no locks -- this may block.
<almuhs> */
<almuhs>azert: isn't it equivalent to bound processor?
<azert>Yes, I’d try to get ext2 to thread_assign all his threads on processor zero
<azert>Just as an hack
<azert>To debug the real ext2 on a mountpoint
<gnucode>morning all.
<nikolar>good morning gnu_srs1
<azert>Anyone knows how hard it is to hack an rpc that exposes thread_bind to userspace as a debug interface?
<danmorg>hello #hurd
<danmorg>hello gnucode
<azert>I'm trying to understand processor_sets
<azert>if I understand correctly you need the host privileged port to get the processors
<gnucode>danmorg: how's lxde ?
<gnucode>azert: I thought you just rubbed the magic genie, and it solved all of your problems for you. :)
<gnucode>I am feeling like my T43 is getting faster for some reason...
<gnucode>azert: also what are processor sets?
<danmorg>gnucode: i never tried on the hurd. i am just happy it installed. i rebooted and i was able to log in and use it.
<danmorg>gnucode: i think you said you were not sure if X was going to run... but i do not have the best memory
<azert>gnucode: I've hacked the following
<azert>I wonder if AlmuHS or damo22 can try to run it with an SMP gnumach
<azert>if it works as I understand it should work, then one could use this code in ext2fs in order to boot and then to debug it
<azert>should be run as root
<azert>hi almuhs
<azert>check this:
<almuhs>i tried to reply you before, but the message was not sent
<azert>could you run it as root with an smp gnumach and see if it works?
<almuhs>the smp gnumach don't but, so i don't know how i can to execute it
<almuhs>don't boot
<almuhs>how can i execute this snippet from gnumach?
<azert>there are probably ways
<azert>but you can copy the snippet at the beginning of ext2fs translator
<azert>and see if it solves anything
<almuhs>i think that i have to copy this code in a function inside gnumach
<almuhs>yes, this is the idea
<azert>in ext2fs, not gnumach
<almuhs>i have to remember how to compile that
<almuhs>the code is here
<azert>try to add it just at the beginning of main, maximum it wont do anything
<azert>found a thinko : processor_assign (list[1], name, 1); -> processor_assign (list[1], set, 1);
<almuhs>i'm cloning hurd's upstream
<almuhs>ok, i think that i have to compile hurd from the hurd VM
<almuhs>i delay a time
<azert>I'd also remove the various printf ,  I'm not sure translators can print on the screen
<gnucode>X does run on the Hurd.
<gnucode>I am currently using it.
<gnucode>If you ever want to run X, and it refuses to start, let me know.
<gnucode>there's a debian command that you might have to run to get X to start.
<gnucode>and filesystem corruption is certain to eventually happen. X needs to write a file in ~/ . If you boot and /home is NOT writeable, then X will look like it is starting...but then the hurd will lock up and freeze.
<gnucode>So you have to umount /home; ext2.fsck /home; then reboot.
<gnucode>there are some more gotchas.
<gnucode>I think I will go document those gotchas now.
<gnucode>azert: cool code snippet!
<gnucode>If you are interested in debbugging booting stuff, then you should talk to sergey.
<gnucode>solid_black I think is his nick.
<gnucode>He had a proposal on irc with damo22 about changing the way the hurd boots.
<gnucode>the irc log of that conversation was amazing!
<gnucode>that alternative boot proposal should also be something that I document on the wiki.
<azert>gnucode: it is really just an hack, but might be very useful
<azert>I saw the plan of sergey
<gnucode>azert: the plan is to help users know if they are booting via SMP or not?
<gnucode>I'm not sure what your code is trying to do.
<azert>no the code is tying whoever run it to one processor
<azert>bind it basically
<azert>the problem with smp is that there are races in ext2fs
<azert>so this would solve them temporarily until they get fixed
<azert>it would allow people to debug the issues