IRC, freenode, #hurd, 2013-08-13
In context of resource management problems.
<braunr> and thread migration itself is something very confusing <braunr> it's better to think of it as scheduling context inheritance <teythoon> braunr: I read the paper I mentioned and then I wanted to find the sources they modified <teythoon> I failed <teythoon> I hate scientific paper about software that fail to provide the source code <teythoon> that's not science imho b/c it's not reproducible <braunr> i have some osf source code here <braunr> i'll send it if you want <teythoon> ah interesting <braunr> but really, when you dive into it, thread migration is merely scheduling context inheritance with kernel upcalls <braunr> it's good <teythoon> I searched for osf mach but google didn't turned up anything <braunr> but it has nothing to do with resource accounting <braunr> (well, it may hepl better account for cpu time actually) <braunr> help* <braunr> but that's all <teythoon> why is that all? wouldn't that be transitive and could also be used for i/o accounting? <teythoon> also I tried to find alternative mach implementations <teythoon> I wasn't terribly successful, and some sites are gone or unmaintained for years :/ <braunr> we don't need that for io accountin <braunr> g <braunr> thread migration is a kernel property <braunr> on mach with userspace drivers, io isn't <braunr> mach should only control cpu and memory <braunr> and you though you can account physical memory, you can't transfer virtual memory accounting from one task to another <teythoon> yes, but once all of those resources can be accounted to the thread initiating whatever it needs doing, shouldn't that be much easier? <braunr> teythoon: it's not required for that <braunr> teythoon: keep in mind userspace sees activations <braunr> in a thread migration enabled kernel, activations are what we usually call threads, and threads are scheduling contexts <teythoon> braunr: ok, so TM is not required for accounting, but surely it's a good thing to have, no? <braunr> teythoon: it's required for cpu accounting only <braunr> which is very important :) <braunr> if you look carefully, you'll see hurd servers are what use most cpu <braunr> there is now easy way to know which application actually uses the server <braunr> i personally tend to think more and more that servers *should* impersonate clients <braunr> TM (or rather, scheduling context inheritance) is one step <braunr> it's not enough exactly because it doesn't help with resource accounting <braunr> teythoon: ftp://ftp.mklinux.org/pub/mklinux-pre-R1/SRPMS/sources/osfmk.tar.gz
IRC, freenode, #hurd, 2013-09-02
<teythoon> braunr: btw, I just noticed lot's of #ifdef MIGRATING_THREADS in gnumach, so there was some work being done in that direction? <braunr> gnumach is a fork of mach4 <braunr> at a stage whre migration was being worked on, yes <teythoon> from what I've gathered, gnumach is the only surviving mach4 fork, right? <braunr> yes <braunr> well <braunr> the macos x version is probably one too <braunr> i don't know <teythoon> oh? I read that it was based on mach3 <braunr> it is <braunr> i can't tell how much of mach3 versus mach4 it has, and if it's relevant at all <teythoon> and the osfmach, was that also based on mach4? <braunr> yes <teythoon> ok, fair enough <braunr> that's why i think macos x is based on it too <braunr> i initially downloaded osfmach sources to see an example of how thread migration was used from userspace <braunr> and they do have a special threading library for that
IRC, freenode, #hurd, 2014-02-18
<teythoon> has anyone here ever tried to enable the thread migration bits in gnumach to see where things break and how far that effort has been taken ? <braunr> without proper userspace support, i don't see how this could work <teythoon> but is the kernel part finished or close to being finished ? <braunr> no idea <braunr> i don't think it is <braunr> i didn't see much code related to that feature, and practically none that looked like what the paper described <braunr> some structures, but not used