[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] * [[microkernel/mach/memory_object/discussion]] * [[resource_management_problems]] # IRC, freenode, #hurd, 2013-08-13 In context of [[resource_management_problems]]. and thread migration itself is something very confusing it's better to think of it as scheduling context inheritance braunr: I read the paper I mentioned and then I wanted to find the sources they modified I failed I hate scientific paper about software that fail to provide the source code that's not science imho b/c it's not reproducible i have some osf source code here i'll send it if you want ah interesting but really, when you dive into it, thread migration is merely scheduling context inheritance with kernel upcalls it's good I searched for osf mach but google didn't turned up anything but it has nothing to do with resource accounting (well, it may hepl better account for cpu time actually) help* but that's all why is that all? wouldn't that be transitive and could also be used for i/o accounting? also I tried to find alternative mach implementations I wasn't terribly successful, and some sites are gone or unmaintained for years :/ we don't need that for io accountin g thread migration is a kernel property on mach with userspace drivers, io isn't mach should only control cpu and memory and you though you can account physical memory, you can't transfer virtual memory accounting from one task to another yes, but once all of those resources can be accounted to the thread initiating whatever it needs doing, shouldn't that be much easier? teythoon: it's not required for that teythoon: keep in mind userspace sees activations in a thread migration enabled kernel, activations are what we usually call threads, and threads are scheduling contexts braunr: ok, so TM is not required for accounting, but surely it's a good thing to have, no? teythoon: it's required for cpu accounting only which is very important :) if you look carefully, you'll see hurd servers are what use most cpu there is now easy way to know which application actually uses the server i personally tend to think more and more that servers *should* impersonate clients TM (or rather, scheduling context inheritance) is one step it's not enough exactly because it doesn't help with resource accounting teythoon: ftp://ftp.mklinux.org/pub/mklinux-pre-R1/SRPMS/sources/osfmk.tar.gz # IRC, freenode, #hurd, 2013-09-02 [[!taglink open_issue_documentation]]: move information to [[microkernel/mach/history]]. braunr: btw, I just noticed lot's of #ifdef MIGRATING_THREADS in gnumach, so there was some work being done in that direction? gnumach is a fork of mach4 at a stage whre migration was being worked on, yes from what I've gathered, gnumach is the only surviving mach4 fork, right? yes well the macos x version is probably one too i don't know oh? I read that it was based on mach3 it is i can't tell how much of mach3 versus mach4 it has, and if it's relevant at all and the osfmach, was that also based on mach4? yes ok, fair enough that's why i think macos x is based on it too i initially downloaded osfmach sources to see an example of how thread migration was used from userspace and they do have a special threading library for that # IRC, freenode, #hurd, 2014-02-18 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 ? without proper userspace support, i don't see how this could work but is the kernel part finished or close to being finished ? no idea i don't think it is i didn't see much code related to that feature, and practically none that looked like what the paper described some structures, but not used