Process management

[Pype.Clicker]

I heard something about an extension for adressing more than 4GB memory. Then the GDT-Entries are larger than 8 Byte but I'm not sure about that. I think for simple OS Development 4GB is enough for these days.

This is known as "Physical Address Extension" (cf. section 3-28 from the System Programming Manual of Intel), which came with some PII iirc. It actually take places at Paging level, by sizing-up entries to 64bits, adding a supplementary level (for more PDBRs)

[Whatever5k]

The CPU-registers are saved automatically if a Task-Switch is done. This is why I suggest to make the TaskSwitcher a seperate Task.

Alright, do I have to define my IRQ0 handler as a Task-Gate, then? But I don't think it's a good idea to let the CPU switch the task on *every* clock interrupt, is it?

By the way, is the TSS approach a good one? I mean, what's about software task switching? Where are the differences in the performance, and what is the disadvantage of software task switching?

best regards and many thanks,
A. Blessing

[Pype.Clicker]

having the scheduler running in its own task is one of the most expensive approach. Moreover, you usually don't want to have a task switch -every IRQ0-, because IRQ0 is also used for time management, etc. (for instance, you might wish an IRQ0 every 1/1000th of second to implement precise time-outs, etc.)

So what you usually do is having the scheduler called every few dozens of IRQ0, which clearly requires IRQ0 is not sent thru a task gate.

imho, it is more wise to have your scheduler called in the context of the interrupted process and do a 'ljmp' to the next task if the scheduler decides so.

Finally, software switching (also called stack-based) has been widely discussed in this board, just search for it It is by far the quickest method if your process have similar priviledges, but it becomes more complex to handle when you have some processes with specific IO maps or LDTs (in which case the IO map must be saved/restored by software aswell) i also ignore how FPU can be supported by software stack-switch ...

My own choice was to have stack swithing among threads from the same process and TSS switching between process (one TSS for every process-per-cpu)

[Whatever5k]

Yup, I agree with Pype on the IRQ0 handler - I think it's wiser to use a quantum for a process...
So, is following approach realizable?

1. ISR0 decides to switch a task
2. scheduler picks a process and calls its tss selector (causing task switch)

That's it - end of story? Or is this causing any problem, what do you think?
And my scheduler is quite simple, what about this:

Code: Select all

void scheduler(void)
{
  process *p;
/* round robin - nice and simple */
 p = get_next_process(process_queue);
 cur_process = p;
 p->tss->type = 0x89;
 __asm__("call %0" :: "r" (p->sel));
}

TSS seems to be ok...and it's fine when working on a i386. Still wondering what I need to place in the TSS descriptor. What are common values for limit, base, size and so on?

[Whatever5k]

Damn it - I'm still not sure if I should use software task switching or TSS - software task switching seems simpler for me and saves me from problems like setting up TSS for every process...
But still, is it right that software task switching has problems with user/kernel processes?
And on which architecture is the TSS supported? Only on Intel? What about AMD and other intel-like processor, do they support TSS?

[richie]

Hello again!
TSS is supported on any modern PC CPU. Also an old AMD 386 supports it. It isn'nt just afeature of Intel CPUs.

[distantvoices]

Ad tss or software task switching: Well, I think, I gonna do tss taskswitches first, before I go to finer-grained thread-Process distinction as Pype has presented.

I gonna have the scheduler be called under two circumstances:

1. A Userprocess has expired its timeslice.
2. An Interrupt has occured and fired off an event: Disk IO ready, Keyboard input, Network Card received Data etc...

case 1: Timer Interrupt increments the ticks consumed value in the current process struct and if a certain value is reached, it calls the scheduler to have the process queued at the end and set another runnable process to be started.

case 2: hardware event - IRQ: Immediate scheduling of the corresponding Kernel Thread to take care of the hardware it is responsible for. thus, I think, I will design the drivers as threads in the kernel. If this approach is good or not, I will see. *gg* In This case the Scheduler will be called immediately. Its an event from hardware and is more important than the actual user process, because buffers can be overwritten, hardware states can be lost ...

ad Mr. Senjak: Gosh, You 've mixed it a little bit, didn't you? It is the idt which has not to contain more than 256 entries according to intel manuals. In the gdt there is plenty of space.


stay safe

[Perica]

..

[distantvoices]

Perica,

it is f. ex. a page directory or a page table, which can hold up to 1024 entries.

the gdt can hold about 8000 entries. Look at the comment of richie about that. He has explained it.

stay safe

[Ozguxxx]

hi people, a cool argument is going on here, which I am really intrested in. First of all beyond infinity, it is a good idea to implement device drivers as high priority tasks themselves because it solves some problems about your scheduling policy but also it adds some other stuff because you also have to implement ipc which starts some other complicating stuff. In fact, writing drivers as tasks is an advice of tanenbaum. So that os becomes something like: A scheduler and a bunch of processes waiting to be runned. Anyway, I just wanted to say that I liked the idea. Do you agree?
My question is: I agree with you that switching to scheduler per every some clock ticks is very time consuming. But as Pype Clicker says, if interrupt is handled in context of interrupted process and not sceduler then the place where you leave interrupted process (if scheduler preempt this process) will be in the middle of handling an interrupt right? So when you switch back to it then we will get a problem. Pype Clicker: I know that I had asked this question before but I could not get the answer. ;D Thanx...

[Pype.Clicker]

There will be no problem with having the process returned (switched back) in the middle of an interrupt handler if you did every interrupt handling task just before you jumped the new task. That's exactly what i did with Clicker between v0.6.* and 0.8.4 (XLR8 extension activated)

Let's figure out how it'll work:

A.1 : interrupt arise
+-- increase uptime(), etc
...
+-- outb(0x20,0x20)
+-- call the 'scheduler' : reduce quantum, etc
| +-- scheduler decides to switch to B
| +-- some internal cleanup & stuff
| +-- ljmp B_Task:0
=== interrupted EIP/ESP:user->IRQ0->scheduler, IF=0 ======

B.1 : started (let's say it never ran before)
+-- starts at process entry point
+-- call to sleep(x)
| +-- call the scheduler
| | +-- decides to switch back to A
| | +-- ljmp A_Task:0
=== interrupted, EIP/ESP:user->sleep->scheduler, IF=1 =====

A.2: resumed
| (just after ljmp B_Task:0)
| +-- return
+-- pop registers (end of IRQ processing)
+-- IRET (restores IF=1, etc.
user process goes on.

And, to abless:
You should better use a JMP TSS rather than CALL TSS for your task switching. CALL TSS implies IRETD will return to the caller task, which makes little sense in the case of independent process switched in a round-robin manner...

[distantvoices]

ozguxx:

In Fact, I have studied tanenbaums os-book, so I am somewhat inspired by his design

so i will have: the scheduling and interrupts mechanism at the very bottom level - I think it will also handle the message passing -> because they are basic functions. One could also call them OS-Primitives.

and around these bottom mechanisms, i will have kernel threads and user processes(and user threads). I don't think I want to have the memory manager and file system be user level processes, but I can't argue AGAINST tanenbaums approach of having them be user-processes. It is just a point of how to do things.

[Whatever5k]

Alright, guys - I decided to change sides, I'm gonna implement software task switching. You have better control of the state with software task switching and you don't have to worry with allocating/freeing TSS and TSS descriptors...
Anyway, I think I *have* to have at least *one* TSS, when ring 3 tasks call ring 0 code (system call)...
Anyone can confirm that please?

[Pype.Clicker]

Alright, guys - I decided to change sides, I'm gonna implement software task switching. You have better control of the state with software task switching and you don't have to worry with allocating/freeing TSS and TSS descriptors...
Anyway, I think I *have* to have at least *one* TSS, when ring 3 tasks call ring 0 code (system call)...
Anyone can confirm that please?

confirmed. Just in order to read the SS0:ESP0 for handling interrupts
What Linux 2.2.x and above actually do is allocating one TSS per CPU.

[Whatever5k]

Well, if I use software task switching combined with *one* TSS, I don't have the portability argument anymore, do I?