From: Nate C. <nat...@na...> - 2004-09-03 20:50:04
Attachments:
config-2.4.27-nomodules
config-2.4.26-modules
|
Hello, I'm working on building a UML host that will have some untrusted users with root access, so I'm trying to build a UML kernel without modules and such. Problem is, on the monolithic kernel, if I do any intensive disk access (ie, running bonnie++), the networking and console hang until the disk access is completed. With a modular kernel, I do not have this problem - the UML session responds normally. I've attached config files for both kernels - anyone have advice on what I could do to solve this? Thanks! ------------------------------------------------------------------------ | nate carlson | nat...@na... | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981 | ------------------------------------------------------------------------ |
From: BlaisorBlade <bla...@ya...> - 2004-09-04 16:57:28
|
Alle 22:49, venerd=EC 3 settembre 2004, Nate Carlson ha scritto: > Hello, > > I'm working on building a UML host that will have some untrusted users > with root access, so I'm trying to build a UML kernel without modules and > such. > > Problem is, on the monolithic kernel, if I do any intensive disk access > (ie, running bonnie++), the networking and console hang until the disk > access is completed. With a modular kernel, I do not have this problem - > the UML session responds normally. The problem is the CONFIG_BLK_DEV_UBD_SYNC=3Dy option (i.e. "always use=20 synchronous ubd access"). Turn it off. If you need more safety, replace, on= =20 the UML command line, ubd0=3D... with ubd0s=3D... (which activates the=20 synchronous mode in a faster way); and please tell me if even with ubd0s=3D= =2E..=20 the system works well. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nate C. <nat...@na...> - 2004-09-04 17:27:36
|
On Sat, 4 Sep 2004, BlaisorBlade wrote: > The problem is the CONFIG_BLK_DEV_UBD_SYNC=y option (i.e. "always use > synchronous ubd access"). Turn it off. If you need more safety, replace, > on the UML command line, ubd0=... with ubd0s=... (which activates the > synchronous mode in a faster way); and please tell me if even with > ubd0s=... the system works well. Ah, yes, that makes sense - I will give that a shot when I return to the office on Monday. Thanks! ------------------------------------------------------------------------ | nate carlson | nat...@na... | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981 | ------------------------------------------------------------------------ |
From: Nate C. <nat...@na...> - 2004-09-07 20:55:33
|
On Sat, 4 Sep 2004, BlaisorBlade wrote: > The problem is the CONFIG_BLK_DEV_UBD_SYNC=y option (i.e. "always use > synchronous ubd access"). Turn it off. If you need more safety, replace, > on the UML command line, ubd0=... with ubd0s=... (which activates the > synchronous mode in a faster way); and please tell me if even with > ubd0s=... the system works well. Ah, that fixed the issue - thanks! With ubd0s=, bonnie works just fine. ------------------------------------------------------------------------ | nate carlson | nat...@na... | http://www.natecarlson.com | | depriving some poor village of its idiot since 1981 | ------------------------------------------------------------------------ |
From: tim d. <ti...@on...> - 2004-09-07 21:47:16
|
So, to summarize... It is good to compile your Host with CONFIG_BLK_DEV_UBD_SYNC==n, and in your startup scripts, set ubd0s=rootfs ubd1s=/someotherfile etc... This will result in a net performance gain on disk io for the host, without the jfs crash downsides? Could you explain, please, where the advantage in io comes from? :} Thanks, Tim Nate Carlson wrote: > On Sat, 4 Sep 2004, BlaisorBlade wrote: > >> The problem is the CONFIG_BLK_DEV_UBD_SYNC=y option (i.e. "always use >> synchronous ubd access"). Turn it off. If you need more safety, >> replace, on the UML command line, ubd0=... with ubd0s=... (which >> activates the synchronous mode in a faster way); and please tell me >> if even with ubd0s=... the system works well. > > > Ah, that fixed the issue - thanks! > > With ubd0s=, bonnie works just fine. > > ------------------------------------------------------------------------ > | nate carlson | nat...@na... | http://www.natecarlson.com | > | depriving some poor village of its idiot since 1981 | > ------------------------------------------------------------------------ > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > -- Timothy Doyle Senior Software Engineer New Generation Media ti...@un... 707-360-1428 2455 Bennett Valley Rd. Suite A215 Santa Rosa, CA 95404 */\/\/\/\/\/\/\/\/\/\/* |
From: BlaisorBlade <bla...@ya...> - 2004-09-09 19:15:24
Attachments:
uml-use-always-io-thread.patch
|
On Tuesday 07 September 2004 23:46, tim doyle wrote: > So, to summarize... > > It is good to compile your Host with CONFIG_BLK_DEV_UBD_SYNC==n, and in > your startup scripts, > set ubd0s=rootfs ubd1s=/someotherfile etc... > > This will result in a net performance gain on disk io for the host, > without the jfs crash downsides? Yes, at all. Jeff, you agree, don't you? > Could you explain, please, where the advantage in io comes from? The IO is always synchronous. But in the better case it's performed by a separate thread (which will wait for the IO to complete), while in the other case it's performed by the main UML thread, which will wait for IO completion, remaining idle meanwhile, while instead it could do anything else (like letting another UML process run or perform tasks which don't require those datas). In fact, I wrote a patch so using CONFIG_BLK_DEV_UBD_SYNC will become like using ubd0s= ubd1s=... (attached, applies onto 2.6.7 and nearby kernel, should apply on 2.4 too). Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Jeff D. <jd...@ad...> - 2004-09-10 02:55:32
|
bla...@ya... said: > The IO is always synchronous. But in the better case it's performed by > a separate thread (which will wait for the IO to complete), while in > the other case it's performed by the main UML thread, which will wait > for IO completion, remaining idle meanwhile, while instead it could > do anything else (like letting another UML process run or perform > tasks which don't require those datas). In fact, I wrote a patch so > using CONFIG_BLK_DEV_UBD_SYNC will become like using ubd0s= ubd1s=... This is just broken. I have no idea how it got this way. These are two entirely different sorts of synchronous. CONFIG_BLK_DEV_UBD_SYNC originally did (O_SYNC or !O_SYNC) IO in process context rather than in the io_thread. ubd=sync or ubd*s do O_SYNC IO to the host. I can't remember why CONFIG_BLK_DEV_UBD_SYNC was added, which is always a bad sign. Maybe it was a debugging crutch. I think it should just be removed. Jeff |
From: BlaisorBlade <bla...@ya...> - 2004-09-10 18:03:28
|
On Friday 10 September 2004 05:55, Jeff Dike wrote: > bla...@ya... said: > > The IO is always synchronous. But in the better case it's performed by > > a separate thread (which will wait for the IO to complete), while in > > the other case it's performed by the main UML thread, which will wait > > for IO completion, remaining idle meanwhile, while instead it could > > do anything else (like letting another UML process run or perform > > tasks which don't require those datas). In fact, I wrote a patch so > > using CONFIG_BLK_DEV_UBD_SYNC will become like using ubd0s= ubd1s=... > > This is just broken. I have no idea how it got this way. These are two > entirely different sorts of synchronous. CONFIG_BLK_DEV_UBD_SYNC > originally did (O_SYNC or !O_SYNC) IO in process context rather than in the > io_thread. ubd=sync or ubd*s do O_SYNC IO to the host. 1) Well, doing it in process context is not useful for additional safety, right? The end_request is done anyway after completing everything. 2) ubd=sync actually does O_SYNC and process context, i.e. it's a synonym for CONFIG_BLK_DEV_UBD_SYNC (no difference, except being compile-time or runtime). > I can't remember why CONFIG_BLK_DEV_UBD_SYNC was added, which is always a > bad sign. Maybe it was a debugging crutch. I think it should just be > removed. No, or people who need "synchronous" will have to adjust their boot script. Instead, just make either CONFIG_BLK_DEV_UBD_SYNC or ubd=sync mean "O_SYNC on all Ubd's". This actually translates to this patch: diff -puN arch/um/drivers/ubd_kern.c~uml-use-always-io-thread arch/um/drivers/ubd_kern.c --- uml-linux-2.6.8.1/arch/um/drivers/ubd_kern.c~uml-use-always-io-thread 2004-09-08 19:16:10.130135096 +0200 +++ uml-linux-2.6.8.1-paolo/arch/um/drivers/ubd_kern.c 2004-09-08 19:16:10.132134792 +0200 @@ -788,9 +788,11 @@ int ubd_driver_init(void){ unsigned long stack; int err; + /* Set by CONFIG_BLK_DEV_UBD_SYNC or ubd=sync.*/ if(global_openflags.s){ - printk(KERN_INFO "ubd : Synchronous mode\n"); - return(0); + printk(KERN_INFO "ubd: Synchronous mode\n"); + /* Letting ubd=sync be like using ubd#s= instead of ubd#= is + * enough. So use anyway the io thread. */ } stack = alloc_stack(0, 0); io_pid = start_io_thread(stack + PAGE_SIZE - sizeof(void *), _ I've not removed the code for the process context case, yet, because it's still used if UML fails starting the IO thread. And, also, a new debug option for the process context I/O (just for developers) should be added. I need that the process context code is not thrown away. That code could maybe be removed, but I'd rather wait for that since it will be needed for future work - the code needs to be almost rewritten to support BIO requests for better performance, and while this is easy for the process context case, it's harder for the IO thread case, even because doing the write 512 bytes at a time is against the purpose of using BIOs. So, the bitmap processing must be thrown away and replaced with something extent-based. And since a BIO is a collection of read/writes, we should also use writev()/ readv(). If possible, I would just boil down the IO thread and replace that with AIO, but that will come later (since that would cause problems to many people). Actually, I want to create a "newubd" driver (which can replace the current one at compile-time) with higher performances, while keeping the old code available. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |