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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox