From: Alex Lyashkov <shadow@psoft.net>
To: Herbert Poetzl <herbert@13thfloor.at>
Cc: Jeff Dike <jdike@addtoit.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [ckrm-tech] Re: [RFC] Revised CKRM release
Date: Sun, 02 May 2004 15:28:29 +0300 [thread overview]
Message-ID: <1083500909.9054.2.camel@berloga.shadowland> (raw)
In-Reply-To: <20040501144624.GA26495@MAIL.13thfloor.at>
В Сбт, 01.05.2004, в 17:46, Herbert Poetzl пишет:
> On Sat, May 01, 2004 at 09:10:15AM +0300, Alex Lyashkov wrote:
> > ? ???, 01.05.2004, ? 02:43, Herbert Poetzl ?????:
> > > On Fri, Apr 30, 2004 at 06:17:39PM -0400, Jeff Dike wrote:
> > > > nagar@watson.ibm.com said:
> > > > > Jeff, do you have any numbers for UML overhead in 2.6 ?
> > > >
> > > > It obviously depends on the workload, but for "normal" things, like kernel
> > > > builds and web serving, it's generally in the 20-30% range. That can be
> > > > reduced, since I haven't spent too much time on tuning. I'm aiming for the
> > > > teens, and I don't think that'll be too hard.
> > >
> > > hmm, just wanted to mention that linux-vserver has
> > > around 0% overhead and often allows to improve
> > > performance due to resource sharing ...
> > >
> > Herber please not say vserver have - 0 overhead.
> > it generally wrong.
>
> well, I said around 0%, but it's actually a long time
> since we measured that, and I'll schedule some
> tests next week, to see if the overhead is still
> not measureable with 'normal' userspace testing
>
Try compare system with 10 vsevers with with 1000 iptables rules per
vserver and routing tables who has more one then one record :) and
system without vservers with same setings ( 1000 iptables rules and some
roting table). Other point who been slowly in vserver large sockets
lists - try use 1000 simultaneous tcp connections per vserver .....
and other... :)
without iptables and 1-10 tcp connections per vserver you can`t find a
speed decrease.
Also fix bugs with wrong selected source address for packets who send
from vserver.
>
> > But overhead less than UML is right.
>
> that is for sure, and it benefits from not having
> everything twice, like inode cache, dentry cache,
> page cache ...
>
> best,
> Herbert
>
> > > basically it's a soft partitioning concept based on
> > > 'Security Contexts' which allow to create many
> > > independant Virtual Private Servers (VPS), which
> > > act simultaneously on one box at full speed, sharing
> > > the available hardware resources.
> > >
> > > see http://linux-vserver.org for details ...
> > >
> > > best,
> > > Herbert
> > >
> > > PS: UML and Linux-VServer play together nicely ...
> > >
> > > >
> > > > Jeff
> > > >
> > > > -------------------------------------------------------
> > > > This SF.Net email is sponsored by: Oracle 10g
> > > > Get certified on the hottest thing ever to hit the market... Oracle 10g.
> > > > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > > > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > > > _______________________________________________
> > > > ckrm-tech mailing list
> > > > https://lists.sourceforge.net/lists/listinfo/ckrm-tech
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> > --
> > Alex Lyashkov <shadow@psoft.net>
> > PSoft
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Alex Lyashkov <shadow@psoft.net>
PSoft
next prev parent reply other threads:[~2004-05-02 12:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-29 8:25 [RFC] Revised CKRM release Shailabh Nagar
2004-04-30 16:41 ` Christoph Hellwig
2004-04-30 18:42 ` Shailabh
2004-04-30 19:03 ` [ckrm-tech] " Rik van Riel
2004-04-30 19:17 ` Shailabh Nagar
2004-04-30 19:31 ` Rik van Riel
2004-04-30 20:15 ` Shailabh Nagar
2004-05-01 13:07 ` Hubertus Franke
2004-04-30 22:43 ` Jeff Dike
2004-04-30 19:47 ` Shailabh
2004-04-30 22:17 ` Jeff Dike
2004-04-30 23:43 ` Herbert Poetzl
2004-05-01 6:10 ` Alex Lyashkov
2004-05-01 14:46 ` Herbert Poetzl
2004-05-02 12:28 ` Alex Lyashkov [this message]
2004-05-04 17:29 ` Marcelo Tosatti
2004-05-04 18:13 ` [ckrm-tech] " Hubertus Franke
2004-05-04 17:35 ` Marcelo Tosatti
2004-05-05 0:18 ` [ckrm-tech] " Shailabh Nagar
2004-05-05 18:48 ` Marcelo Tosatti
2004-05-06 0:00 ` Chandra Seetharaman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1083500909.9054.2.camel@berloga.shadowland \
--to=shadow@psoft.net \
--cc=herbert@13thfloor.at \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.