* microkernel/mach/deficiencies.mdwn: link to the resource management page.
* microkernel/mach/gnumach/memory_management.mdwn: link to the resource management page. * open_issues/resource_management_problems.mdwn: I added in 3 paragraphs from an old email that explained this problem really well. --- microkernel/mach/deficiencies.mdwn | 17 +++++++++ .../mach/gnumach/memory_management.mdwn | 1 + open_issues/resource_management_problems.mdwn | 36 ++++++++++++++++--- 3 files changed, 50 insertions(+), 4 deletions(-) diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 8b137891..fcf86d79 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -1 +1,18 @@ +[[!meta copyright="Copyright © 2024 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 stable_URL]] + +* [[open_issues/resource_management_problems]] + +* [[IPC issues|microkernel/mach/gnumach/projects/mach_5]] + +* [[microkernel/mach/gnumach/projects/clean_up_the_code]] diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn index 477f0a18..6eca2bce 100644 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -13,6 +13,7 @@ License|/fdl]]."]]"""]] [[!toc]] +A related page is the [[open_issues/resource_management_problems]]. # IRC, freenode, #hurd, 2011-02-15 diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index daf97954..51025d34 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2013, 2024 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 @@ -18,8 +18,36 @@ 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]]. +<!-- the following 3 paragraphs comes from this email: + lists.gnu.org/archive/html/bug-hurd/2009-07/msg00084.html --> + +This is the fundamental failing of the Mach/Hurd architecture. The +Hurd operates via many server to client relationships, in which +servers request resources on behalf of their clients. For example at +any given time, `extfs` could have many different clients (emacs, vim, +git etc.) requesting data, creating files, deleting files, re-naming +files, etc. Suppose one rogue client out of 50 is continually +requesting increasingly more memory, which is exhasting the machine's +resources. As far as Mach knows, `ext2fs` is wasting RAM. It doesn't +know that one `ext2fs`' client program is at fault. There is no way +for Mach to fix this, since it should not kill `ext2fs`, and it cannot +know which `ext2fs` client to kill. + +This server/client architecture is a problem that exists elsewhere. A +good example is `X`. Firefox might allocate a lot of pixmaps, which +causes `X` to use more memory. Linux actually used to kill X, because +of this several years ago. + +This problem is much worse on a multiserver system, because we have +many server/client relationships. A simple fix that would limit these +issues is to introduce fixed limits on various kinds of resource +usage. A proper fix requires a way to attribute all resource usage to +the clients -- either by avoiding server-side allocation or by keeping +track of who is requesting resources. Both of these changes requires +lots of changes to low-level code. + +These issues are what Neal Walfield explored with his on with his +kernel [[microkernel/viengoos]]. # Kernel -- 2.45.2
