From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- .../mach_migrating_threads.mdwn | 118 --------------------- 1 file changed, 118 deletions(-) delete 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 deleted file mode 100644 index 16547838..00000000 --- a/service_solahart_jakarta_selatan__082122541663/mach_migrating_threads.mdwn +++ /dev/null @@ -1,118 +0,0 @@ -[[!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