Re: Mach lack for frequent operations
<[EMAIL PROTECTED]> writes: >- Fork is a hard cost operation. > > To get an idea how hard fork() is for us, Gianluca did a simple test, > on GNU/Hurd he got 312 forks/second, and on the same machine but in > GNU/Linux, he got 8170 forks/second. Roland and I many years ago came to the conclusion that the primary cost of fork is the cost of scanning and duplicating the port space of the task correctly. We put on the task list the addition of a new kernel RPC that would do the main job of that duplication in a single context switch. Thomas ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
On 12/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > To get an idea how hard fork() is for us, Gianluca did a simple test, > on GNU/Hurd he got 312 forks/second, and on the same machine but in > GNU/Linux, he got 8170 forks/second. FYI, I just compiled and executed under linux and under hurd the forks benchmark code provided with hurd (in benchmark/forks.c). Results were very 'stable' in Hurd and the forks per second rate was incredibly constant. I made the test for benchmarking the improvements that GNU Mach could have by supporting the PGE bit functionality available in Pentium and later processors: basically you set Kernel's page table entries as 'global' thus they are not invalidated during a context switch; this lead to an often noticeable improvement in context switching performance, but in the GNU Mach + GNU Hurd case, the overall system improvement was a crappy +3% in the forks test. Regards, Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire confidence at all. Later I learned that I had been introduced to electronic engineers. E. W. Dijkstra ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
- Fork is a hard cost operation. To get an idea how hard fork() is for us, Gianluca did a simple test, on GNU/Hurd he got 312 forks/second, and on the same machine but in GNU/Linux, he got 8170 forks/second. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
I think this is a implementation problem, there is no way to fix it. Maybe this can be fixed rebuilding all Mach infrastructure. Can anyone confirm that? The problems with Mach can be fixed by redesigning the way how IPC's works. Rebuilding the whole Mach infrastructure is a possiblity, but it requires more work than simply redesigning core parts of Mach. Note that is isn't a problem only in Mach, the Hurd needs to be tweaked too. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
I think this is a implementation problem, there is no way to fix it. Maybe this can be fixed rebuilding all Mach infrastructure. Can anyone confirm that? Thanks Matheus Morais On 11/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Sorry for the late response. Can anyone explain why that overhead happen in Mach?The large overhead is mostly related to how the Hurd uses Mach. Running a single-user server system gets you quite decent performance,but we have a multi-sever design, where the number of contextswitches, and IPC overhead is becomes far larger. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
The GNU/Mach misses lot of optimization tips. Most of these tips was discussed in the Hurdmeeting: - Memory objects cache doesn't works. - Main function (mach_msg) length is 1300 lines. - No multipage transfer support (k0ro fixes that) - Fork is a hard cost operation. Implementing transfers by object references may increase the performance for most IPC operations in the Mach. (no user-kernel kernel-user transactions). -pancake On Thu, 01 Dec 2005 01:34:30 +0100 <[EMAIL PROTECTED]> wrote: > Sorry for the late response. > >Can anyone explain why that overhead happen in Mach? > > The large overhead is mostly related to how the Hurd uses Mach. > Running a single-user server system gets you quite decent performance, > but we have a multi-sever design, where the number of context > switches, and IPC overhead is becomes far larger. > > > ___ > Bug-hurd mailing list > Bug-hurd@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-hurd ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
Sorry for the late response. Can anyone explain why that overhead happen in Mach? The large overhead is mostly related to how the Hurd uses Mach. Running a single-user server system gets you quite decent performance, but we have a multi-sever design, where the number of context switches, and IPC overhead is becomes far larger. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Mach lack for frequent operations
At Fri, 18 Nov 2005 17:34:12 -0200,
Matheus Morais <[EMAIL PROTECTED]> wrote:
>
> Quoted from Microkernels, Úlfar Erlingsson and Athanasios Kyparlis
> "For some frequent operations, e.g. networking, the overhead of
> context-switching was too great for an out-of-kernel implementation. Thus
> the microkernels were not as efficient as originally thought."
>
> I can't understand why for some frequent operations microkernels are not
> efficient as originally thought. I thinking is why IPC cost on Mach is very
> high. Its that true? Can anyone explain why that overhead happen in Mach?
This is not generally true for microkernels, but certainly for Mach.
The main problem with the Mach kernel is the "substantially higher
cache-miss rate", which is a result of Mach, not of the client-server
design. A good introduction to this topic, and references to further
information, is contained in:
http://www.marcus-brinkmann.org/cap-papers/Year/1996.complete.html#Lie96
@Article{Lie96,
author = {Jochen Liedtke},
title = {Toward Real µ-kernels},
journal = {Communications of the ACM},
month = {September},
year = {1996},
volume = {39},
number = {9},
pages = {70--77},
abstract = {The inefficient, inflexible first generation inspired
development of the vastly improved second generation, which may yet
support a variety of operating systems.},
keyword = {L4, Design Principles},
url = {http://www.l4ka.org/publications/1996/towards-ukernels.pdf},
url = {http://www.l4ka.org/publications/1996/towards-ukernels.ps},
citeseer-url = {http://citeseer.ist.psu.edu/liedtke96toward.html}
}
Thanks,
Marcus
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
