Re: A question
On Tue, 20 Jun 2000, Alan Cox wrote: > > various extended features (which few use) can then be easily added > > on a personal basis. I doubt that ELKS has ever run more than 15 > > processes, for instance. > > For reference the standard V7 builds were for about 30-60 processes (60 being > a big box). Oh, ok, I had no idea of the scale. Forget what I wrote *grin*. > > > Groeten, Dries
Re: A question
> cases even ELKS code is too complicated. Alan has pointed this > out with the #ifdef madness and other very little used options. Most of IFDEFs were there due to bugs in the source .. old code was just #if 0ed out and replaced with new one. At least that's what i did in parts of kernel i touched; Al then included whole patch (or file), without removing old code. Anyway, it was harmless. > on a personal basis. I doubt that ELKS has ever run more than 15 > processes, for instance. No, it probably hasn't. I had some 10 running but then again i was only testing it. If there was _any_ daemon present it would occupy another process slot, ... bye, Ab
Re: A question
: For ELKS it isnt worth it. For real Linux it would be (and in fact it does : it all with lists) Although these suggestions about making extendable sleep structs are laudable, I, for one, agree with Alan. I think ELKS is a great learning tool, and should function simply. I've found that in many cases even ELKS code is too complicated. Alan has pointed this out with the #ifdef madness and other very little used options. The ELKS project should function as simple as possible, IMHO; various extended features (which few use) can then be easily added on a personal basis. I doubt that ELKS has ever run more than 15 processes, for instance. Regards, Greg
Re: A question
> various extended features (which few use) can then be easily added > on a personal basis. I doubt that ELKS has ever run more than 15 > processes, for instance. For reference the standard V7 builds were for about 30-60 processes (60 being a big box).
Re: A question
On Tue, 20 Jun 2000, Larry Howard Mittman wrote: > Alan Cox wrote: > > > > hybrid crossing between the V7 and the linux method. Like allocating a > > > relatively small struct, but then make it an option to grow the struct by > > > making a linked list of these structs. Given the low computative power of > > > > The struct size is fixed - I dont follow you > > If I understand him correctly, the idea is to make the struct one node of a > Btree -like construct. > IE: (struct-of 2-or3-processes)(link to next struct) > That way, with a minimal amount of processes (2,3,4, or 5) you would have one > struct, just as you > described. But, if you try to have more, the struct chain grows by another > struct (2,3,4,or 5), etc... > If you are crazy enough to have MANY processes, the chain would grow > accordingly and so would > the time necessary to traverse it. But with a small amount, (small being > relative to personal taste), the > response would be acceptable. This is exactly what I mean. This would make ELKS scalable enough for the people stupid enough to try *grin*. > > -- > == > Never cross a Dragon, for you are crunchy and taste delicious! > My Interests are: > Ham Radio (N8MGU) | Opera | Theater | Sailing | Judaica > > > Groeten, Dries
Re: A question
> >From what I understand, using the task struct to keep track of sleeping > processes, limits the number of processes the kernel can handle. If you In a sense since wakeup is O(N) by number of processes > processes, you can increase functionality. If the number of sleeping > processes is more then a certain number, you can activate the pointer and > the kernel can follow the pointer like in a linked list. So you don't > really use a linked list like linux does, but you use an array and when > it's full, you can point to another array. For ELKS it isnt worth it. For real Linux it would be (and in fact it does it all with lists) > >
Re: A question
Alan Cox wrote: > hybrid crossing between the V7 and the linux method. Like allocating a > relatively small struct, but then make it an option to grow the struct by > making a linked list of these structs. Given the low computative power of The struct size is fixed - I dont follow you If I understand him correctly, the idea is to make the struct one node of a Btree -like construct. IE: (struct-of 2-or3-processes)(link to next struct) That way, with a minimal amount of processes (2,3,4, or 5) you would have one struct, just as you described. But, if you try to have more, the struct chain grows by another struct (2,3,4,or 5), etc... If you are crazy enough to have MANY processes, the chain would grow accordingly and so would the time necessary to traverse it. But with a small amount, (small being relative to personal taste), the response would be acceptable. -- == Never cross a Dragon, for you are crunchy and taste delicious! My Interests are: Ham Radio (N8MGU) | Opera | Theater | Sailing | Judaica
Re: A question
On Tue, 20 Jun 2000, Alan Cox wrote: > > hybrid crossing between the V7 and the linux method. Like allocating a > > relatively small struct, but then make it an option to grow the struct by > > making a linked list of these structs. Given the low computative power of > > The struct size is fixed - I dont follow you >From what I understand, using the task struct to keep track of sleeping processes, limits the number of processes the kernel can handle. If you allow a situation where the list of sleeping processes is stored in the task struct, but can also contain a pointer to another list of sleeping processes, you can increase functionality. If the number of sleeping processes is more then a certain number, you can activate the pointer and the kernel can follow the pointer like in a linked list. So you don't really use a linked list like linux does, but you use an array and when it's full, you can point to another array. I usually only do a bit of kernel module programming and I'm following the ELKS mailing in hope of learning a bit more about things like scheduling, so forgive me if what I say sound a bit stupid *grin*. Groeten, Dries
Re: A question
> If I understand him correctly, the idea is to make the struct one node of a
> Btree -like construct.
> IE: (struct-of 2-or3-processes)(link to next struct)
Nope..
The code might be the simplest explanation here
diff -u --new-file --recursive --exclude-from /usr/src/exclude elks/kernel/sleepwake.c
elks-ac/kernel/sleepwake.c
--- elks/kernel/sleepwake.c Thu Aug 19 16:13:55 1999
+++ elks-ac/kernel/sleepwake.c Mon Jun 19 15:14:01 2000
@@ -10,84 +10,52 @@
* Copyright (C) 1991, 1992 Linus Torvalds
* Elks tweaks (C) 1995 Alan Cox.
*
+ * Copyright (C) 2000 Alan Cox.
+ * Rewrote the entire queue functionality to reflect ELKS actual needs
+ * not Linux needs
*/
-void add_wait_queue(p,wait)
-register struct wait_queue **p;
-register struct wait_queue *wait;
+void wait_set(p)
+register struct wait_queue *p;
{
- flag_t flags;
- save_flags(flags);
- icli();
- if(!*p)
- {
- wait->next = wait;
- *p = wait;
- }
- else
- {
- wait->next = (*p)->next;
- (*p)->next = wait;
- }
- restore_flags(flags);
+ if(current->waitpt)
+ panic("double wait");
+ current->waitpt=p;
}
-void remove_wait_queue(p,wait)
-struct wait_queue **p;
-register struct wait_queue *wait;
+void wait_clear(p)
+struct wait_queue *p;
{
- flag_t flags;
- save_flags(flags);
- icli();
- if((*p==wait) && ((*p=wait->next)==wait))
- *p=NULL;
- else
- {
- register struct wait_queue *tmp=wait;
- while(tmp->next != wait)
- tmp = tmp->next;
- tmp->next = wait->next;
- }
- wait->next=NULL;
- restore_flags(flags);
+ if(current->waitpt!=p)
+ printk("wrong waitpt");
+ current->waitpt=NULL;
}
int marker;
static void __sleep_on(p,state)
-register struct wait_queue **p;
+register struct wait_queue *p;
int state;
{
- flag_t flags;
- struct wait_queue wait;
-
- wait.next=NULL;
- wait.task = current;
-
- if(!p)
- return;
if(current==&task[0]) {
printk("task[0] trying to sleep ");
panic("from %x", marker);
}
current->state = state;
- add_wait_queue(p, &wait);
- save_flags(flags);
- isti();
+ wait_set(p);
schedule();
- remove_wait_queue(p, &wait);
- restore_flags(flags);
+ wait_clear(p);
}
void sleep_on(p)
-struct wait_queue **p;
+struct wait_queue *p;
{
marker = peekw(get_ds(), get_bp() + 2);
__sleep_on(p, TASK_UNINTERRUPTIBLE);
}
void interruptible_sleep_on(p)
-struct wait_queue **p;
+struct wait_queue *p;
{
__sleep_on(p, TASK_INTERRUPTIBLE);
}
@@ -127,54 +95,29 @@
*/
void _wake_up(q,it)
-struct wait_queue **q;
+struct wait_queue *q;
int it;
{
- register struct wait_queue *tmp;
- register struct task_struct * p;
-
- if (!q || !(tmp = *q))
- return;
- do {
- if ((p = tmp->task) != NULL) {
- if ((it && (p->state == TASK_UNINTERRUPTIBLE)) ||
- (p->state == TASK_INTERRUPTIBLE))
- wake_up_process(p);
- }
- if (!tmp->next) {
- printk("wait_queue is bad\n");
- printk("q = %x\n",q);
- printk(" *q = %x\n",*q);
- printk(" tmp = %x\n",tmp);
- break;
- }
- tmp = tmp->next;
- } while (tmp != *q);
-}
-
-#ifdef NOTYET
-void wake_up_interruptible(q)
-struct wait_queue **q;
-{
- register struct wait_queue *tmp;
register struct task_struct * p;
-
- if (!q || !(tmp = *q))
- return;
- do {
- if ((p = tmp->task) != NULL) {
- if (p->state == TASK_INTERRUPTIBLE)
+ int phash = 1<>4)&15);
+ extern struct wait_queue select_poll;
+
+ for_each_task(p)
+ {
+ if(p->waitpt==q)
+ {
+ if(p->state == TASK_INTERRUPTIBLE ||
+ (it && p->state == TASK_UNINTERRUPTIBLE))
wake_up_process(p);
}
- if (!tmp->next) {
- printk("wait_queue is bad\n");
- printk("q = %p\n",q);
- printk(" *q = %p\n",*q);
- printk(" tmp = %p\n",tmp);
- break;
+ if(p->waitpt==&select_poll)
+ {
+ if(p->pollhash&phash)
+ {
+ if(p->state == TASK_INTERRUPTIBLE ||
+
Re: A question
> hybrid crossing between the V7 and the linux method. Like allocating a > relatively small struct, but then make it an option to grow the struct by > making a linked list of these structs. Given the low computative power of The struct size is fixed - I dont follow you
Re: A question
On Tue, 20 Jun 2000, Alan Cox wrote: > > Could anyone explain me what is a V7 like wakeup mechanism? > > Old old unix systems took the address of the thing they wanted to wait on > and placed it in the task structure. Since the number of processes is pretty > low its easy for the CPU to walk the process table on a wakeup checking > if the 'wakeup' for this process matches the value it is given to wake. Since a realloc is a pretty expensive call, this pretty much means that you have to allocate enough memory for the task struct to fit every process you will be running. This would mean that you have to allocate too much memory to be on the safe side. Isn't it possible to make a kind of hybrid crossing between the V7 and the linux method. Like allocating a relatively small struct, but then make it an option to grow the struct by making a linked list of these structs. Given the low computative power of the machines ELKS runs on, I can imagine that you could choose the memory in such a way that a all kernel processes, with a few users processes (say 2 or 3) fit in on struct and that if the user is stupid enough to try to do serious multitasking on his 8086 or palm pilot, the kernel allocates another struct, the pointer to which is stored in the original struct. This way you have the best of both worlds it would seem. Is this stupid? Has it been tried? Groeten, Dries
