Thread (13 messages) flat view 13 messages, 3 authors, 2011-07-07

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

From: Loke, Chetan <hidden>
Date: 2011-07-05 22:27:27
Also in: linux-mm

-----Original Message-----
From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
Sent: July 05, 2011 3:19 PM
To: Loke, Chetan; netdev@vger.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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help