From: Tim W. <ti...@ge...> - 2005-06-24 11:53:35
|
> On Friday 24 June 2005 13:24, Tim Warnock wrote: > > Ive got a 170mb root fs im trying to use through a ramdisk > > > > mem=3D256M ramdisk=3D190000 root=3D/dev/ram > This way you're creating a ramdisk inside UML and using it as=20 > root, which=20 > won't work. What you want would be ubd0=3D/dev/ram or something=20 > like that. I wanted the ramdisk inside of the uml for performance. If it worked, would it have performed better being inside the uml or as a ubd? Thanks Tim Warnock ISP Technical Manager GetOnIt! Nationwide Internet. 1300 88 00 97 timoid (at) getonit.net.au=20 |
From: Tim W. <ti...@ge...> - 2005-06-24 21:35:45
|
> > I wanted the ramdisk inside of the uml for performance. > Yes, it makes sense, and would perform better, but how do you=20 > put the datas on the root_fs inside the ramfs? By copying it > at boot time using hostfs only. No im not. I was expecting the linux process to populate /dev/ram with the contents of the gunzipped image exactly as it would in the real world. > Are you doing that in your initrd script? Also, I think that=20 > /dev/ram will=20 > refer to the initrd itself (though I'm not sure). > > If it worked, would it have performed better being inside=20 > the uml or as > > a ubd? > Well, the caching would improve performances with a more=20 > limited memory use.=20 > If you want to keep things in ram, you might as well copy the=20 > root_fs inside=20 > a tmpfs mount. > However, you need to save the changes to the root_fs... which=20 > might be done=20 > easily well if you use a COW file which you put on a normal disk. I'll explain what im doing. UML incorporates a very buggy driver. Its not UML's fault the driver is buggy but theres being no work done on it. The driver is EQL. EQL will take a whole system down if you lose two or more ppp slaves in one EQL schedule and theres data to be sent. So, what I wanted to do was use EQL inside of UML have it that if the uml process "kernel paniced" my script would detect and clean up and then reload the os again from ramdisk. No information loss because its all in ramdisk - designed to be volatile. Thanks Tim Warnock ISP Technical Manager GetOnIt! Nationwide Internet. 1300 88 00 97 timoid (at) getonit.net.au=20 =20 |
From: Blaisorblade <bla...@ya...> - 2005-06-25 09:57:32
|
On Friday 24 June 2005 23:35, Tim Warnock wrote: > > > I wanted the ramdisk inside of the uml for performance. > > > > Yes, it makes sense, and would perform better, but how do you > > put the datas on the root_fs inside the ramfs? By copying it > > at boot time using hostfs only. > > No im not. I was expecting the linux process to populate /dev/ram with > the contents of the gunzipped image exactly as it would in the real > world. Ah, ok... I was expecting this to happen too, except that I hadn't understood that your root_fs had been gzipped and used as initrd. And it seems that root=/dev/ram should make it work as normal root_fs (even if I think that trying root=/dev/ram0 is useful). Since I've not clear what's happening here (and yes, initrd handling should not be different from real world), here's a few ideas: However, there are a bit of limitations in that, you're not allowed to use a reiserfs root filesystem for this. Also, if you use ext2 images, the blocksize when generating the filesystem must sometimes match the one used for the ramdisk (i.e. you'll probably add ramdisk_blocksize=4096). Well, in that case the only problem I can think of is that a initrd is expected to be a bit different ... you'd need to supply a /linuxrc file inside it. It can mount the real root and continue or boot directly the system (I've seen both things in practice and I don't know the difference). Also all the docs I see talk about /dev/ram0, not /dev/ram (but in the source I see /dev/ram). > > Are you doing that in your initrd script? Also, I think that > > /dev/ram will > > refer to the initrd itself (though I'm not sure). > I'll explain what im doing. UML incorporates a very buggy driver. > Its > not UML's fault the driver is buggy but theres being no work done on it. > The driver is EQL. EQL will take a whole system down if you lose two or > more ppp slaves in one EQL schedule and theres data to be sent. So, what > I wanted to do was use EQL inside of UML have it that if the uml process > "kernel paniced" my script would detect and clean up and then reload the > os again from ramdisk. No information loss because its all in ramdisk - > designed to be volatile. Hmm, interesting, ok. However with your design the ramdisk would be copied and decompressed each time at UML boot, which might be undesirable (or not, YMMV). -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Tim W. <ti...@ge...> - 2005-06-25 11:32:56
|
I realised two things were wrong: My image is 256000 bytes decompressed, even though theres only 180mb of data on the drive. So I have to specify: ramdisk_blocksize=3D1024 (at = bb's recommendation) and ramdisk_size=3D256000 bytesize of the decompressed image. Cmd line: mem=3D320M Memory: 239052k available At 320mb there isnt enough ram to load the image into the ram disk. It boots as expected if I specify mem=3D340M which leave 259052kb of ram available... But why isnt it crashing out of ram, rather than just chewing cpu cycles? And where is the rest of the ram going? Its missing about 80mb... Thanks Tim Warnock ISP Technical Manager GetOnIt! Nationwide Internet. 1300 88 00 97 timoid (at) getonit.net.au=20 |
From: Blaisorblade <bla...@ya...> - 2005-06-27 16:27:48
|
On Saturday 25 June 2005 13:32, Tim Warnock wrote: > I realised two things were wrong: > My image is 256000 bytes decompressed, even though theres only 180mb of > data on the drive. So I have to specify: ramdisk_blocksize=1024 (at bb's > recommendation) and ramdisk_size=256000 bytesize of the decompressed > image. > Cmd line: mem=320M > Memory: 239052k available > At 320mb there isnt enough ram to load the image into the ram disk. Hmm, it must load the whole compressed image in memory and then decompress it.... > It boots as expected if I specify mem=340M which leave 259052kb of ram > available... > But why isnt it crashing out of ram, rather than just chewing cpu > cycles? Probably it's looping in the crash handler... (that's a bug of course). > And where is the rest of the ram going? Its missing about > 80mb... Can you post the exact free output? I guess you're astonished because you're looking at the -/+ buffers/cache, which isn't exactly right here, because the ramdisk memory is put in buffers. > Thanks > Tim Warnock -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
From: Blaisorblade <bla...@ya...> - 2005-06-24 18:14:13
|
On Friday 24 June 2005 13:53, Tim Warnock wrote: > > On Friday 24 June 2005 13:24, Tim Warnock wrote: > > > Ive got a 170mb root fs im trying to use through a ramdisk > > > > > > mem=256M ramdisk=190000 root=/dev/ram > > > > This way you're creating a ramdisk inside UML and using it as > > root, which > > won't work. What you want would be ubd0=/dev/ram or something > > like that. > I wanted the ramdisk inside of the uml for performance. Yes, it makes sense, and would perform better, but how do you put the datas on the root_fs inside the ramfs? By copying it at boot time using hostfs only. Are you doing that in your initrd script? Also, I think that /dev/ram will refer to the initrd itself (though I'm not sure). > If it worked, would it have performed better being inside the uml or as > a ubd? Well, the caching would improve performances with a more limited memory use. If you want to keep things in ram, you might as well copy the root_fs inside a tmpfs mount. However, you need to save the changes to the root_fs... which might be done easily well if you use a COW file which you put on a normal disk. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |