Re: [uml-devel] UBD performance
On Sun, Oct 09, 2005 at 09:35:15PM -0400, Jeff Dike wrote: > On Sun, Oct 09, 2005 at 11:51:28PM +0100, Chris Lightfoot wrote: > > (TBH I'm surprised that the AIO code shows so little > > improvement. The kernel does report that it's using 2.6 > > host AIO, so it is using the new version. Obviously > > issuing the writes segment-by-segment is non-ideal but I'm > > surprised it's this bad. Could I be missing some > > configuration step?) > > Make sure you've got the o_direct patch, and are using a 4K block filesystem. > > If you're not doing O_DIRECT, then io_getevents waits - i.e. it's synchronous. OK. The host is indeed using a 4K block filesystem; I couldn't find your O_DIRECT patch, but turning on O_DIRECT with fcntl just after opening the backing file gives these results: http://ex-parrot.com/~chris/tmp/20051010/host-vs-uml-io-results-3.png i.e., the AIO implementation is now slower than the stock implementation for writes of size up to about 8KB, but faster for larger writes; it's still quite a bit slower than the host. -- Never has one man's death brought so much pleasure to so many people (newspaper obituary of Stalin) --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Blank process command lines in 2.6.13.2?
On Mon, Oct 10, 2005 at 12:10:10AM -0500, Rob Landley wrote: > Any likelihood that at some point in the future it could accidentally point > to > something it would be a bad idea to display? I think the worst case is skas3 with no stack randomization, where that page will point somewhere into the process stack. There is some slight possibility that something could store a password on its stack, and have that end up in the area that the host ps looks for arguments. This would make the password visible on the host for the time that this process in context. With stack randomization, the UML process stacks will be located elsewhere almost all the time, so with skas3, there is a smaller chance that there will be a visible password there. With skas0, that page is the stub signal stack, which contains no sensitive information. Jeff --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] [PATCH] slight UML config simplification.
On Sun, Oct 09, 2005 at 05:38:20PM -0500, Rob Landley wrote: > My limiting factor is learning what they are. :) Actually, I just took care of the rest of them. Jeff --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] UBD performance
On Mon, Oct 10, 2005 at 10:10:24AM +0100, Chris Lightfoot wrote: > OK. The host is indeed using a 4K block filesystem; I > couldn't find your O_DIRECT patch, but turning on O_DIRECT > with fcntl just after opening the backing file gives these > results: > http://ex-parrot.com/~chris/tmp/20051010/host-vs-uml-io-results-3.png > i.e., the AIO implementation is now slower than the stock > implementation for writes of size up to about 8KB, but > faster for larger writes; it's still quite a bit slower > than the host. There aren't very good labels on that graph, but it looks consistent with my experience, which is 25-30% faster kernel builds with AIO/O_DIRECT. The next question is where the slowdown is happening. Jeff --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] UBD performance
On Mon, Oct 10, 2005 at 10:38:03AM -0400, Jeff Dike wrote: > On Mon, Oct 10, 2005 at 10:10:24AM +0100, Chris Lightfoot wrote: > > OK. The host is indeed using a 4K block filesystem; I > > couldn't find your O_DIRECT patch, but turning on O_DIRECT > > with fcntl just after opening the backing file gives these > > results: > > http://ex-parrot.com/~chris/tmp/20051010/host-vs-uml-io-results-3.png > > i.e., the AIO implementation is now slower than the stock > > implementation for writes of size up to about 8KB, but > > faster for larger writes; it's still quite a bit slower > > than the host. > > There aren't very good labels on that graph, but it looks consistent with my > experience, which is 25-30% faster kernel builds with AIO/O_DIRECT. Not sure what additional labels you want, but here are the raw results (format as described previously): http://caesious.beasts.org/~chris/tmp/20051010/uml-2.6.12.5 http://caesious.beasts.org/~chris/tmp/20051010/uml-2.6.12.5-128M http://caesious.beasts.org/~chris/tmp/20051010/uml-2.6.12.5-newubd http://caesious.beasts.org/~chris/tmp/20051010/uml-2.6.13.3-aio http://caesious.beasts.org/~chris/tmp/20051010/uml-2.6.13.3-aio-direct http://caesious.beasts.org/~chris/tmp/20051010/host-2.6.13.3-skas3-v9-pre7-skas3-v7 http://caesious.beasts.org/~chris/tmp/20051010/host-cfq-2.6.13.3-skas3-v9-pre7-skas3-v7 -- names should be self-explanatory. > The next question is where the slowdown is happening. Well, it's got to be either O_DIRECT, aio, or breaking the requests up, I guess -- ``My years of hip-hop sessions came in handy as I could converse well with Fast Fingers. I knew the lingo and when to use it, and as far as he was concerned, I was one of the brothers. Strangely, neither of us was one of the brothers, but I figure that's just a technicality.'' (`MixerMan') --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Blank process command lines in 2.6.13.2?
On Monday 10 October 2005 09:36, Jeff Dike wrote: > I think the worst case is skas3 with no stack randomization, where that > page will point somewhere into the process stack. There is some slight > possibility that something could store a password on its stack, and have > that end up in the area that the host ps looks for arguments. This would > make the password visible on the host for the time that this process in > context. I'm not so worried about sensitive info because in the parent kernel you can just attach to the process from a debugger (although not necessarily as a different, normal user). I'm actually slightly more concerned about high ascii garbage or who knows what showing up and making ps look really weird. > With stack randomization, the UML process stacks will be located > elsewhere almost all the time, so with skas3, there is a smaller > chance that there will be a visible password there. > > With skas0, that page is the stub signal stack, which contains no sensitive > information. Is there any way to move the stub signal stack on skas0 by one page so that we can still have ps on the parent system look right? I don't know how hard that is. (Is there a design document for -skas0 anywhere? I found the /dev/anon page...) Rob --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
[uml-devel] [PATCH] UML - revert block driver use of host AIO
The patch to use host AIO support that I submitted early after 2.6.13 exposed
some problems in the block driver. I have fixes for these, but am not
comfortable putting them into 2.6.14 at this late date. So, this patch reverts
the use of host AIO.
I will resubmit the original patch, plus fixes to the driver after 2.6.14
in order to get a reasonable amount of testing before they're exposed to
the general public.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
Index: linux-2.6.14-rc3/arch/um/drivers/Makefile
===
--- linux-2.6.14-rc3.orig/arch/um/drivers/Makefile 2005-10-10
12:02:08.0 -0400
+++ linux-2.6.14-rc3/arch/um/drivers/Makefile 2005-10-10 23:04:53.0
-0400
@@ -13,7 +13,7 @@
net-objs := net_kern.o net_user.o
mconsole-objs := mconsole_kern.o mconsole_user.o
hostaudio-objs := hostaudio_kern.o
-ubd-objs := ubd_kern.o
+ubd-objs := ubd_kern.o ubd_user.o
port-objs := port_kern.o port_user.o
harddog-objs := harddog_kern.o harddog_user.o
Index: linux-2.6.14-rc3/arch/um/drivers/ubd_kern.c
===
--- linux-2.6.14-rc3.orig/arch/um/drivers/ubd_kern.c2005-10-10
12:02:08.0 -0400
+++ linux-2.6.14-rc3/arch/um/drivers/ubd_kern.c 2005-10-10 23:04:53.0
-0400
@@ -35,7 +35,6 @@
#include "linux/blkpg.h"
#include "linux/genhd.h"
#include "linux/spinlock.h"
-#include "asm/atomic.h"
#include "asm/segment.h"
#include "asm/uaccess.h"
#include "asm/irq.h"
@@ -54,21 +53,20 @@
#include "mem.h"
#include "mem_kern.h"
#include "cow.h"
-#include "aio.h"
enum ubd_req { UBD_READ, UBD_WRITE };
struct io_thread_req {
- enum aio_type op;
+ enum ubd_req op;
int fds[2];
unsigned long offsets[2];
unsigned long long offset;
unsigned long length;
char *buffer;
int sectorsize;
- int bitmap_offset;
- long bitmap_start;
- long bitmap_end;
+ unsigned long sector_mask;
+ unsigned long long cow_offset;
+ unsigned long bitmap_words[2];
int error;
};
@@ -82,31 +80,28 @@
unsigned long *bitmap_len_out,
int *data_offset_out);
extern int read_cow_bitmap(int fd, void *buf, int offset, int len);
-extern void do_io(struct io_thread_req *req, struct request *r,
- unsigned long *bitmap);
+extern void do_io(struct io_thread_req *req);
-static inline int ubd_test_bit(__u64 bit, void *data)
+static inline int ubd_test_bit(__u64 bit, unsigned char *data)
{
- unsigned char *buffer = data;
__u64 n;
int bits, off;
- bits = sizeof(buffer[0]) * 8;
+ bits = sizeof(data[0]) * 8;
n = bit / bits;
off = bit % bits;
- return((buffer[n] & (1 << off)) != 0);
+ return((data[n] & (1 << off)) != 0);
}
-static inline void ubd_set_bit(__u64 bit, void *data)
+static inline void ubd_set_bit(__u64 bit, unsigned char *data)
{
- unsigned char *buffer = data;
__u64 n;
int bits, off;
- bits = sizeof(buffer[0]) * 8;
+ bits = sizeof(data[0]) * 8;
n = bit / bits;
off = bit % bits;
- buffer[n] |= (1 << off);
+ data[n] |= (1 << off);
}
/*End stuff from ubd_user.h*/
@@ -115,6 +110,8 @@
static DEFINE_SPINLOCK(ubd_io_lock);
static DEFINE_SPINLOCK(ubd_lock);
+static void (*do_ubd)(void);
+
static int ubd_open(struct inode * inode, struct file * filp);
static int ubd_release(struct inode * inode, struct file * file);
static int ubd_ioctl(struct inode * inode, struct file * file,
@@ -161,8 +158,6 @@
int data_offset;
};
-#define MAX_SG 64
-
struct ubd {
char *file;
int count;
@@ -173,7 +168,6 @@
int no_cow;
struct cow cow;
struct platform_device pdev;
-struct scatterlist sg[MAX_SG];
};
#define DEFAULT_COW { \
@@ -466,114 +460,81 @@
);
static void do_ubd_request(request_queue_t * q);
-static int in_ubd;
+
+/* Only changed by ubd_init, which is an initcall. */
+int thread_fd = -1;
/* Changed by ubd_handler, which is serialized because interrupts only
* happen on CPU 0.
*/
int intr_count = 0;
-static void ubd_end_request(struct request *req, int bytes, int uptodate)
-{
- if (!end_that_request_first(req, uptodate, bytes >> 9)) {
- add_disk_randomness(req->rq_disk);
- end_that_request_last(req);
- }
-}
-
/* call ubd_finish if you need to serialize */
-static void __ubd_finish(struct request *req, int bytes)
+static void __ubd_finish(struct request *req, int error)
{
- if(bytes < 0){
- ubd_end_request(req, 0, 0);
- return;
- }
+ int nsect;
- ubd_end_request(req, bytes, 1);
+ if(error){
+ end_request(req, 0);
+ return;
+ }
+ nsect = req->current_nr_sectors;
+ req->sector += ns
