netdev - RE: [RFC] non-preemptible kernel socket for RAMster

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <D3F292ADF945FB49B35E96C94C2061B91257DCA8@nsmail.netscout.com>
Date:	Tue, 5 Jul 2011 18:27:22 -0400
From:	"Loke, Chetan" <Chetan.Loke@...scout.com>
To:	"Dan Magenheimer" <dan.magenheimer@...cle.com>,
	<netdev@...r.kernel.org>
Cc:	"Konrad Wilk" <konrad.wilk@...cle.com>,
	"linux-mm" <linux-mm@...ck.org>
Subject: RE: [RFC] non-preemptible kernel socket for RAMster

> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@...cle.com]
> Sent: July 05, 2011 3:19 PM
> To: Loke, Chetan; netdev@...r.kernel.org
> Cc: Konrad Wilk; linux-mm
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
> 

> Actually, RAMster is using a much more flexible type of
> RAM-drive; it is built on top of Transcendent Memory
> and on top of zcache (and thus on top of cleancache and
> frontswap).  A RAM-drive is fixed size so is not very suitable
> for the flexibility required for RAMster.  For example,
> suppose you have two machines A and B.  At one point in
> time A is overcommitted and needs to swap and B is relatively
> idle.  Then later, B is overcommitted and needs to swap and
> A is relatively idle.  RAMster can handle this entirely
> dynamically, a RAM-drive cannot.

Again, iff NBD works with a ram-drive then you really wouldn't need to
do anything. How often are you going to re-size your remote-SWAP?  Plus,
you can make nbd-server listen on multiple ports - Google(Linux NBD)
returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
nbd-server code to see if it launches multiple kernel-threads for
servicing different ports. If not, one can enhance it and scale that way
too. But nbd-server today can service multiple-ports(that is effectively
servicing multiple clients). So why not add NBD-filesystem-filters to
make it point to local/remote swap?

> 
> Thanks.  Could you provide a pointer for this?  I found
> the SCST sourceforge page but no obvious references to
> scst-in-ram-mode.  (But also, since it appears to be
> SCSI-related, I wonder if it also assumes a fixed size
> target device, RAM or disk or ??)
> 

Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
docs and then send an email to the scst-mailing-list. If you speak about
block-IO-performance then FC(in its class of price/performance factor)
is more than capable of handling any workload. FC is a protocol designed
for storage. No exotic fabric other than FC is needed.
Folks who start with ethernet for block-IO, always start with bare
minimal code and then for squeezing block-IO performance(aka version 2
of the product), keep hacking repeatedly or go for a link-speed upgrade.
Start with FC, period.

> Dan

Chetan Loke
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html