From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../mach_migrating_threads.mdwn | 118 +++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 service_solahart_jakarta_selatan__082122541663/mach_migrating_threads.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/mach_migrating_threads.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/mach_migrating_threads.mdwn b/service_solahart_jakarta_selatan__082122541663/mach_migrating_threads.mdwn new file mode 100644 index 00000000..16547838 --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/mach_migrating_threads.mdwn @@ -0,0 +1,118 @@ +[[!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 -- cgit v1.2.3