diff options
Diffstat (limited to 'open_issues/performance/microkernel_multi-server.mdwn')
| -rw-r--r-- | open_issues/performance/microkernel_multi-server.mdwn | 47 |
1 files changed, 0 insertions, 47 deletions
diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn deleted file mode 100644 index 111d2b88..00000000 --- a/open_issues/performance/microkernel_multi-server.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -[[!meta copyright="Copyright © 2011 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_documentation]] - -Performance issues due to the microkernel/multi-server system architecture? - -IRC, freenode, #hurd, 2011-07-26 - - < CTKArcher> I read that, because of its microkernel+servers design, the - hurd was slower than a monolithic kernel, is that confirmed ? - < youpi> the hurd is currently slower than current monolithic kernels, but - it's not due to the microkernel + servers design - < youpi> the microkernel+servers design makes the system call path longer - < youpi> but you're bound by disk and network speed - < youpi> so the extra overhead will not hurt so much - < youpi> except dumb applications keeping doing system calls all the time - of course, but they are usually considered bogus - < braunr> there may be some patterns (like applications using pipes - extensively, e.g. git-svn) which may suffer from the design, but still in - an acceptable range - < CTKArcher> so, you are saying that disk and network are more slowing the - system than the longer system call path and because of that, it wont - really matter ? - < youpi> braunr: they should sitll be fixed because they'll suffer (even if - less) on monolithic kernels - < youpi> CTKArcher: yes - < braunr> yes - < CTKArcher> mmh - < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 - iirc, about minix - < youpi> they even go as far as using an IPC for each low-level in/out - < youpi> for security - < braunr> this has been expected for a long time - < braunr> which is what motivated research in microkernels - < CTKArcher> I've already downloaded the video :) - < youpi> and it has been more and more true with faster and faster cpus - < braunr> but in 95, processors weren't that fast compared to other - components as they are now - < youpi> while disk/mem haven't evovled so fast |