Applied, thanks! jbra...@dismail.de, le jeu. 17 oct. 2024 02:06:08 -0400, a ecrit: > * 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 > >
-- Samuel void packerFlushTheToiletFirstThingInTheMorning( void* arg ) -+- chromium's source code -+-
