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. --- open_issues/resource_management_problems.mdwn | 131 ++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 open_issues/resource_management_problems.mdwn (limited to 'open_issues/resource_management_problems.mdwn') diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn new file mode 100644 index 00000000..daf97954 --- /dev/null +++ b/open_issues/resource_management_problems.mdwn @@ -0,0 +1,131 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 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 open_issue_hurd open_issue_viengoos]] + +[[microkernel/Mach]] interfaces do not allow for proper resource accounting, +when a server allocates resources on behalf of a client. + +Mach can't do a good job at resource management, as it doesn't have enough +information how resources are used: which data is important and which is +discardable, for example. + +These issues are what Neal Walfield is working on with his new kernel +[[microkernel/viengoos]]. + + +# Kernel + +Inside the [[kernel]], there is commonly a need to allocate resources according +to externally induced demand, dynamically. For example, for memory-management +data structures (page tables), process table entries, thread control blocks, +[[capability]] tables, incoming network packages, blocks that are read in from +disk, the keyboard type-ahead buffer for a in-kernel keyboard driver. Some of +these are due to actions driven by user-space requests, others are due to +actions internal to the the kernel itself. Some of these buffers can be sized +statically (keyboard type-ahead buffer), and are thus unproblematic. Others +are not, and should thus be attributed to their user space entities. In the +latter (ideal) case, all resources -- that is, including those needed inside +the kernel -- that a user space task needs for execution are provided by itself +(and, in turn, provided by its parent / principal), and the kernel itself does +not need to allocate any resources dynamically out of an its own memory pool. +This avoids issues like [[microkernel/Mach]]'s [[zalloc_panics]] upon user +space processes allocating too many [[microkernel/mach/port]]s, for example. + +[[!toggleable id=fof_plos09 text="""[[!template id=note +text="*[[fof\_plos09|microkernel/barrelfish]]*: +{{$microkernel/barrelfish#fof_plos09}}"]]"""]] + +[[!toggleable id=sel4 text="""[[!template id=note +text="[[*sel4*|microkernel/l4]]: {{$microkernel/l4#sel4}}"]]"""]] + +In [[!toggle id=fof_plos09 text="[fof\_plos09]"]], the authors describe in +section 3 how they model their [[capability]] system according to [[!toggle +id=sel4 text="[sel4]"]] using a *retype* operation that *takes an existing +capability and produces one or more derived capabilities [...] used to create +new kernel-level memory objects (such as page tables or execution contexts) +from capabilities to raw regions of RAM*. + +This is, of course, non-trivial to implement, and also requires changing the +[[RPC]] interfaces, for example, but it is a valid approach, a research topic. + +([[!taglink open_issue_documentation]]: compare this to Linux [`vmsplice`'s +SPLICE_F_GIFT +flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) + + +## IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + + +## IRC, freenode, #hurd, 2013-08-13 + +In context of . + + teythoon: actually, thread migration isn't required for resource + accounting + +[[Mach_migrating_threads]]. + + braunr: but it solves it for free, doesn't it? + teythoon: no + it's really more complicated than that + + +# Further Examples + + * [[hurd/critique]] + + * [[IO_accounting]] + + * [[translators_set_up_by_untrusted_users]], and [[pagers]] + + * [[configure_max_command_line_length]] + + +## [[hurd/translator/exec]] server + +### IRC, freenode, #hurd, 2013-08-05 + + unzipping stuff in the exec server enables a dos on filesystem + translators + https://teythoon.cryptobitch.de/gsoc/heap/hello-1g.bz2 is + /hurd/hello padded with a gig of zeros, compressed with bzip2 + if set as an passive translator, it stalls other requests to the + filesystem, at least it does if ext2fs is used + teythoon: ? + teythoon: what's the dos here ? + I can prevent you from doing anything with the root filesystem + I'm kind of surprised myself, maybe a lock is held during the + exec of the translator? + the filesystem the hello-1g.bz2 translator is bound to is + affected + teythoon: i don't understand + have you tried starting something from another file system ? + the lock may simply be in the exec server itself + no, starting other things works fine + but on the other hand, a find / is stalled + :/ + *sigh* + don't worry + there is a solution :p + :) + and it only requires deleting code -- cgit v1.2.3