Swap support

Swap support

[Harry Kalogirou]

Hi all!!

Yesterday I commited to the CVS some experimental swap support code,
based on Alan's work on the subject. Ofcourse this code is not included
in the default configuration and is not for _actual_ use, since as I
said is experimental. Apart from that if you set the swap partition in
malloc.c you and enable swapping you can enjoy an 8086 system use
_virtual_ memory! 

I also added a utility named "meminfo" in the elkscmd package under the
sys_utils directory to monitor the memory usage.

Harry

Re: Swap support

[Dave Chavez]

Javier Sedano wrote:

> Harry Kalogirou wrote:
> 
> '> Yesterday I commited to the CVS some experimental swap support code,
> 
>>based on Alan's work on the subject. Ofcourse this code is not included
>>in the default configuration and is not for _actual_ use, since as I
>>said is experimental. Apart from that if you set the swap partition in
>>malloc.c you and enable swapping you can enjoy an 8086 system use
>>_virtual_ memory!
>>
>>
> 
> 	Great!
> 
> 	I've been looking for it in the code, and found nothing about it's
> configuration (setting the partition and the size, activating it...)...
> can someone (Harry, Alan) give us a few words about how to do so?
> 	And by the way... can you write a technical description about how is it
> done? The main problem with swap in minix was (is) that processes
> waiting for IO (waiting for a message from FS) can not be swapped in,
> because they would meet a deadlock when trying to swap out (for FS is
> needed again to do the swapping out, but it is frozen sending the
> message to the process, because FS is not reentrant/concurrent in
> minix)... and obviously processes waiting for IO are those best suited
> to be swapped in.
> 
> 	Excuse my bad English... from memory to disk is "swap in" or "swap
> out"?


Your English is fine, and I'd say "swap out" indicates memory to disk.

Dave

Re: Swap support

[Javier Sedano]

Harry Kalogirou wrote:
> 
'> Yesterday I commited to the CVS some experimental swap support code,
> based on Alan's work on the subject. Ofcourse this code is not included
> in the default configuration and is not for _actual_ use, since as I
> said is experimental. Apart from that if you set the swap partition in
> malloc.c you and enable swapping you can enjoy an 8086 system use
> _virtual_ memory!
> 

	Great!

	I've been looking for it in the code, and found nothing about it's
configuration (setting the partition and the size, activating it...)...
can someone (Harry, Alan) give us a few words about how to do so?
	And by the way... can you write a technical description about how is it
done? The main problem with swap in minix was (is) that processes
waiting for IO (waiting for a message from FS) can not be swapped in,
because they would meet a deadlock when trying to swap out (for FS is
needed again to do the swapping out, but it is frozen sending the
message to the process, because FS is not reentrant/concurrent in
minix)... and obviously processes waiting for IO are those best suited
to be swapped in.

	Excuse my bad English... from memory to disk is "swap in" or "swap
out"?

-- 
Daría todo lo que sé por la mitad de lo que ignoro
--------
Javier Sedano Jarillo      http://www.it.uc3m.es/~jsedano
 jsedano@dit.upm.es (*)
 jsedano@ieee.org
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Swap support

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

Την Δευ, 22-04-2002 στις 16:42, ο/η Javier Sedano έγραψε:
> Harry Kalogirou wrote:
> > 
> '> Yesterday I commited to the CVS some experimental swap support code,
> > based on Alan's work on the subject. Ofcourse this code is not included
> > in the default configuration and is not for _actual_ use, since as I
> > said is experimental. Apart from that if you set the swap partition in
> > malloc.c you and enable swapping you can enjoy an 8086 system use
> > _virtual_ memory!
> > 
> 
> 	Great!
> 
> 	I've been looking for it in the code, and found nothing about it's
> configuration (setting the partition and the size, activating it...)...
> can someone (Harry, Alan) give us a few words about how to do so?

I will focus on making it easily configurable at run time later along
with documenting it a bit. Basicaly the code now is a 4 hour brain
storm. To configure it you basicaly change this part of the code :


	holep = &swap_holes[0];
	holep->flags = HOLE_FREE;
	holep->page_base = 0;
	holep->extent = 128;
	holep->refcount = 0;
	holep->next = NULL;

	swap_dev = 0x0100;

The extent is the size in kilobytes and the swap_dev is the block device
to swap to. In the example 0x0100 is /dev/ram0


> 	And by the way... can you write a technical description about how is it
> done? The main problem with swap in minix was (is) that processes

It's on my TODO list...

> waiting for IO (waiting for a message from FS) can not be swapped in,
> because they would meet a deadlock when trying to swap out (for FS is
> needed again to do the swapping out, but it is frozen sending the
> message to the process, because FS is not reentrant/concurrent in
> minix)... and obviously processes waiting for IO are those best suited
> to be swapped in.
> 

As you might already noticed we don't use the FS layer, we only support
swapping to a device at the momment. Once the think works we can add
swapping to file easily. For the minix matter now - our FS is reentrant
so we will have no problem...

Harry


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: Swap support

[Riley Williams]

Hi Harry.

>>> Yesterday I commited to the CVS some experimental swap support code,
>>> based on Alan's work on the subject. Of course this code is not
>>> included in the default configuration and is not for _actual_ use,
>>> since as I said is experimental. Apart from that if you set the swap
>>> partition in malloc.c you and enable swapping you can enjoy an 8086
>>> system use _virtual_ memory!

>> Great!
>> 
>> I've been looking for it in the code, and found nothing about it's
>> configuration (setting the partition and the size, activating
>> it...)... can someone (Harry, Alan) give us a few words about how to
>> do so?

> I will focus on making it easily configurable at run time later
> along with documenting it a bit. Basicaly the code now is a 4 hour
> brain storm. To configure it you basicaly change this part of the
> code :

>	holep = &swap_holes[0];
>	holep->flags = HOLE_FREE;
>	holep->page_base = 0;
>	holep->extent = 128;
>	holep->refcount = 0;
>	holep->next = NULL;
>
>	swap_dev = 0x0100;

> The extent is the size in kilobytes and the swap_dev is the block
> device to swap to. In the example 0x0100 is /dev/ram0 for example.

Would you mind if I tweaked the config system to allow this to be
configured therein, making the entire configuration dependent on the
CONFIG_EXPERIMENTAL config variable?

Also, does it use any particular format for the swap partition? I'm
presuming from the above that it operates at partition level rather
than at device level, so doesn't require a separate hard drive for
swap usage.

>> And by the way... can you write a technical description about how
>> it is done?

> It's on my TODO list...

I'll have a look as well, and see what I can come up with once I've
finished ANSI'fying the source tree.

>> The main problem with swap in minix was (is) that processes waiting
>> for IO (waiting for a message from FS) can not be swapped in,
>> because they would meet a deadlock when trying to swap out (for FS
>> is needed again to do the swapping out, but it is frozen sending the
>> message to the process, because FS is not reentrant/concurrent in
>> minix)... and obviously processes waiting for IO are those best
>> suited to be swapped in.

> As you might already noticed we don't use the FS layer, we only
> support swapping to a device at the moment. Once the thing works
> we can add swapping to file easily.

That's the best way to do it, IMHO.

> For the minix matter now - our FS is reentrant so we will have no
> problem...

That's one less thing to worry about.

Best wishes from Riley.

Re: Swap support

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Την Δευ, 22-04-2002 στις 21:18, ο/η Riley Williams έγραψε:
> Would you mind if I tweaked the config system to allow this to be
> configured therein, making the entire configuration dependent on the
> CONFIG_EXPERIMENTAL config variable?

Yes make it dependent on CONFIG_EXPERIMENTAL, as for the configuration
of the swap partition leave it as it is now, since it is only for
developers at the moment...

> Also, does it use any particular format for the swap partition? I'm
> presuming from the above that it operates at partition level rather
> than at device level, so doesn't require a separate hard drive for
> swap usage.

There is no need to format the block device(partition) to be used...


Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: Swap support

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Την Δευ, 22-04-2002 στις 21:18, ο/η Riley Williams έγραψε:
> Would you mind if I tweaked the config system to allow this to be
> configured therein, making the entire configuration dependent on the
> CONFIG_EXPERIMENTAL config variable?

Yes make it dependent on CONFIG_EXPERIMENTAL, as for the configuration
of the swap partition leave it as it is now, since it is only for
developers at the moment...

> Also, does it use any particular format for the swap partition? I'm
> presuming from the above that it operates at partition level rather
> than at device level, so doesn't require a separate hard drive for
> swap usage.

There is no need to format the block device(partition) to be used...


Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Introduction and proposal:

[erich alfred heine]

Hello all,

I have recently joined this list, and would like to introduce myself:
Hi im Erich.

Anyway, Ive been playing with ELKS on my 286 laptop for a couple of weeks
now, and i think its way cool. Especially since the hard disk has long
since been kaput.

Ive read a couple emails about the documentation for this project, and I
concur that it does need improvement.  I would like to help out with
documenting this project, while I learn enough about the OS to maybe start
helping with code.

One of the things Ive thought would be neat, is a guide to the source code
of ELKS, like a programmers manual.  Is this something that is needed? Or
would my time be better spent working on other documentation?

Another of the projects related to ELKS that ive been considering, is a
good vt100 emulator, and/or a serial library that would make ELKS good for
controlling devices over a serial line, but I wont be able to consider
working on that till the end of the summer at the earliest.

Anyway, thats all from me, I just figured I would consult you all about
the documentation thing.

Erich Heine

Re: Swap support

[Riley Williams]

Hi Harry.

>> Would you mind if I tweaked the config system to allow this to be
>> configured therein, making the entire configuration dependent on
>> the CONFIG_EXPERIMENTAL config variable?

> Yes make it dependent on CONFIG_EXPERIMENTAL, as for the
> configuration of the swap partition leave it as it is now,
> since it is only for developers at the moment...

No problem. There's two thing that strike me though:

 1. Does it actually make sense to use a ramdisk as a swap drive?

 2. If we're using a hard drive partition as a swap partition,
    doesn't the kernel already know the size of that partition?

If (2) is true, then the extents field is not one needing configuration
anyway as we can just grab the value the kernel has already determined
earlier in the boot process. At least, I hope it has, as it doesn't make
sense for the swap code to be enabled prior to our autoprobing for the
hard drive partition sizes.

>> Also, does it use any particular format for the swap partition?

> There is no need to format the block device (partition) to be used...

True, but it misses what I was asking. Basically, are we emulating the
Linux swap code in this respect, in that we store a swap signature at
the start of the swap partition, or are we just using the partition raw?

>> I'm presuming from the above that it operates at partition level
>> rather than at device level, so doesn't require a separate hard
>> drive for swap usage.

This comment was because your previous phraseology implied that we used
[say] /dev/edb as the swap device, but I suspect we're more likely to be
using [say] /dev/edb1 instead.

Best wishes from Riley.

Re: Swap support

[Harry Kalogirou]

Την Δευ, 22-04-2002 στις 23:35, ο/η Riley Williams έγραψε:
> Hi Harry.
> 
> >> Would you mind if I tweaked the config system to allow this to be
> >> configured therein, making the entire configuration dependent on
> >> the CONFIG_EXPERIMENTAL config variable?
> 
> > Yes make it dependent on CONFIG_EXPERIMENTAL, as for the
> > configuration of the swap partition leave it as it is now,
> > since it is only for developers at the moment...
> 
> No problem. There's two thing that strike me though:
> 
>  1. Does it actually make sense to use a ramdisk as a swap drive?
 
For now it does only for debuging. Later if and when we have  ramdrives
that use memory after 1MB(on 286) it will make sense for more than
debuging.... 

>  2. If we're using a hard drive partition as a swap partition,
>     doesn't the kernel already know the size of that partition?

Yes it does and the swapper will use that info in the next versions. I
just hardcoded in for now since the ramdisk driver does not inform about
the size of the drive and I only use the ramdisk for debuging.....

> If (2) is true, then the extents field is not one needing configuration
> anyway as we can just grab the value the kernel has already determined
> earlier in the boot process. At least, I hope it has, as it doesn't make
> sense for the swap code to be enabled prior to our autoprobing for the
> hard drive partition sizes.
> 
> >> Also, does it use any particular format for the swap partition?
> 
> > There is no need to format the block device (partition) to be used...
> 
> True, but it misses what I was asking. Basically, are we emulating the
> Linux swap code in this respect, in that we store a swap signature at
> the start of the swap partition, or are we just using the partition raw?
 
We are using the partition _raw_. No format is needed(mkswap).

Harry


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

Re: Introduction and proposal:

[Riley Williams]

Hi Erich.

> Anyway, Ive been playing with ELKS on my 286 laptop for a couple of
> weeks now, and i think its way cool. Especially since the hard disk
> has long since been kaput.

It's good to see others are interested. Welcome aboard.

> I've read a couple emails about the documentation for this project,
> and I concur that it does need improvement. I would like to help out
> with documenting this project, while I learn enough about the OS to
> maybe start helping with code.

You're certainly welcome to do that.

> One of the things I've thought would be neat, is a guide to the
> source code of ELKS, like a programmers manual. Is this something
> that is needed? Or would my time be better spent working on other
> documentation?

To be honest, the ELKS documentation in general falls into one or more
of the following categories:

 1. Hopelessly out of date.

 2. Abysmal English. Apparently, the non-English versions are far
    easier to follow than the English ones. (I can't confirm this
    as the only three languages I speak with anything approaching
    fluency are English and American).

 3. Ambiguous phraseology, largely as a result of (1) above.

Anything you can do to help with ANY of the ELKS documentation that
currently exists, or to create QUALITY new documentation, would be
appreciated by far more than just me.

> Another of the projects related to ELKS that I've been considering,
> is a good vt100 emulator, and/or a serial library that would make
> ELKS good for controlling devices over a serial line, but I won't be
> able to consider working on that till the end of the summer at the
> earliest.

I started on a VT100 emulator a while back, but got little further than
documenting some of the control sequences used. ELKS itself uses VT52
sequences for video control, so the emulator would basically consist of
a tool that receives VT100 sequences and generates the equivalent VT52
sequence. If you're interested, I have a genuine VT100 manual that lists
all the codes supported by the hardware in question.

As regards the serial library, ELKS already supports SLIP links, and I
understand that requires the kernel to provide pretty much complete
serial support, so that is probably an unnecessary project.

> Anyway, thats all from me, I just figured I would consult you all
> about the documentation thing.

The basic instruction there has to be "Go ahead".

Best wishes from Riley.

Re: Introduction and proposal:

[Harry Kalogirou]

Την Δευ, 22-04-2002 στις 23:19, ο/η erich alfred heine έγραψε:
> Hello all,
> 
> I have recently joined this list, and would like to introduce myself:
> Hi im Erich.
> 

Nice to meet you!

The only thing I know is that we need documentators badly!!

Harry




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

Re: Introduction and proposal:

[Harry Kalogirou]

Την Δευ, 22-04-2002 στις 23:58, ο/η Riley Williams έγραψε:
> Hi Erich.
> 
> 
> As regards the serial library, ELKS already supports SLIP links, and I
> understand that requires the kernel to provide pretty much complete
> serial support, so that is probably an unnecessary project.
> 

Actualy the serial driver needs some work. Flow control is the priority
one and modem control lines is priority two...

Harry



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

Re: Swap support

[Riley Williams]

Hi Harry.

>>>> Would you mind if I tweaked the config system to allow this to be
>>>> configured therein, making the entire configuration dependent on
>>>> the CONFIG_EXPERIMENTAL config variable?

>>> Yes make it dependent on CONFIG_EXPERIMENTAL, as for the
>>> configuration of the swap partition leave it as it is now,
>>> since it is only for developers at the moment...

>> No problem. There's two thing that strike me though:
>> 
>>  1. Does it actually make sense to use a ramdisk as a swap drive?

> For now it does only for debuging. Later if and when we have
> ramdrives that use memory after 1MB (on 286) it will make sense for
> more than debuging....

Also if we have EMS cards that we support, they could be used for swap
as well as ramdrives.

>>  2. If we're using a hard drive partition as a swap partition,
>>     doesn't the kernel already know the size of that partition?

> Yes it does and the swapper will use that info in the next versions.
> I just hardcoded in for now since the ramdisk driver does not inform
> about the size of the drive and I only use the ramdisk for debugging.

So what you're basically saying is that all storage device drivers need
to include a facility where they can be asked the size of the drive
they're controlling, if I'm understanding that right? After all, it's
not something that could safely be left to even the most experienced
system admin to specify, so there needs to be some means for the swap
system to ask the underlying device/file what its size is.

>> If (2) is true, then the extents field is not one needing
>> configuration anyway as we can just grab the value the kernel has
>> already determined earlier in the boot process. At least, I hope it
>> has, as it doesn't make sense for the swap code to be enabled prior
>> to our autoprobing for the hard drive partition sizes.

>>>> Also, does it use any particular format for the swap partition?

>>> There is no need to format the block device (partition) to be used...

>> True, but it misses what I was asking. Basically, are we emulating
>> the Linux swap code in this respect, in that we store a swap
>> signature at the start of the swap partition, or are we just using
>> the partition raw?

> We are using the partition _raw_. No format is needed(mkswap).

Similar to Linux's mkswap that just drops the signature at the start of
the relevant partition and exits, except our signature is 0 bytes long.

Best wishes from Riley.

Re: Introduction and proposal:

[Riley Williams]

Hi Harry.

>> As regards the serial library, ELKS already supports SLIP links, and
>> I understand that requires the kernel to provide pretty much
>> complete serial support, so that is probably an unnecessary project.

> Actualy the serial driver needs some work. Flow control is the
> priority one and modem control lines is priority two...

Surely that's back to front? The primary flow control is via the CTS
and RTS modem control lines, so flow control can't be fully implemented
before the modem control lines have been implemented.

Best wishes from Riley.

Re: Swap support

[Dan Olson]

> So what you're basically saying is that all storage device drivers need
> to include a facility where they can be asked the size of the drive
> they're controlling, if I'm understanding that right? After all, it's
> not something that could safely be left to even the most experienced
> system admin to specify, so there needs to be some means for the swap
> system to ask the underlying device/file what its size is.

Why not just work towards having a swap partition/file system like that of
Linux?  Then any type of drive (hard drive, RAM drive, even floppy) could
be used for swap, and the size would be known.  Seems like that might make
things easier in the end as well, as the same code could be used for
either swap or a file system on the different types of media available.
Of course raw access is fine for now, just pick a default size for
testing.

	Dan

Re: Swap support

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Την Τρι, 23-04-2002 στις 02:03, ο/η Dan Olson έγραψε:
> > So what you're basically saying is that all storage device drivers need
> > to include a facility where they can be asked the size of the drive
> > they're controlling, if I'm understanding that right? After all, it's
> > not something that could safely be left to even the most experienced
> > system admin to specify, so there needs to be some means for the swap
> > system to ask the underlying device/file what its size is.
> 
> Why not just work towards having a swap partition/file system like that of
> Linux?  Then any type of drive (hard drive, RAM drive, even floppy) could
> be used for swap, and the size would be known.  Seems like that might make
> things easier in the end as well, as the same code could be used for
> either swap or a file system on the different types of media available.
> Of course raw access is fine for now, just pick a default size for
> testing.
> 

I just said that the ramdisk driver doesn't report it's size, others
report it just fine. There is a little structure that contains the size
,among other things, of the device but ramdisk doesn't seem to update
it.

Harry



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: Introduction and proposal:Documentation

[tom potts]

Re Erich's comments:
Documentation is needed - I've tried to do a source
code html browser but the code keeps changing!
Does anyone know of an API for CVS that I can use with
PHP?
Tom 



__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: Introduction and proposal:Documentation

[erich alfred heine]

Wouldnt the LXR engine be able to do that...?
I dont know much about it, but i could look into it, after finals are over
(a week or 2).

Erich Heine

On Tue, 23 Apr 2002, [iso-8859-1] tom potts wrote:

> Re Erich's comments:
> Documentation is needed - I've tried to do a source
> code html browser but the code keeps changing!
> Does anyone know of an API for CVS that I can use with
> PHP?
> Tom
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Swap support

[Harry Kalogirou]

Την Τρι, 23-04-2002 στις 23:03, ο/η Blaz Antonic έγραψε:
> > I just said that the ramdisk driver doesn't report it's size, others
> > report it just fine. There is a little structure that contains the size
> > ,among other things, of the device but ramdisk doesn't seem to update
> > it.
> 
> My bad, this should be easy to add. I was peeking at doshod.c when i was
> writing ramdisk driver, i must have missed the relevant part abot
> updating this thing. If doshd.c does it it should be no biggie (a couple
> of lines of code, namely in function that creates and destroys
> ramdisks).
> 
> Blaz Antonic
> 

You are right, basicaly it just needs a 

blk_size[MAJOR][MINOR] = no_of_1024_byte_blocks;

Harry



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

Re: Swap support

[Blaz Antonic]

> I just said that the ramdisk driver doesn't report it's size, others
> report it just fine. There is a little structure that contains the size
> ,among other things, of the device but ramdisk doesn't seem to update
> it.

My bad, this should be easy to add. I was peeking at doshod.c when i was
writing ramdisk driver, i must have missed the relevant part abot
updating this thing. If doshd.c does it it should be no biggie (a couple
of lines of code, namely in function that creates and destroys
ramdisks).

Blaz Antonic