Modifying proc{} structure

[Ravi L]

Hi,

I am implementing lottery scheduling in Minix. I have just added a new
variable 'tickets' to the end of the proc{} structure in the kernel/
proc.h.

struct proc {
.....
int tickets;
};

I get 'PM: FS died' error when I boot with new image (with my change).
And the OS gets stuck.

I read that when we change 'proc' structure we need to change kernel/
sconst.h also. But, I am not sure what to add there. Can anybody help
me here?

I did not add any other change. I just wanted to check if this works
or not as a starting point. So I just added 'int tickets;' at the end
of the proc structure. And created the image using following commands:

#cd /usr/src/tools && make install
The above step created image as /boot/image/3.1.2ar0
#shutdown
d0p0s0>image=/boot/image/3.1.2ar0
d0p0s0>boot

After I login, it gives me 'PM: FS died' error.

thanks in advance
--ravi

[Rahmat M. Samik-Ibrahim]

On Wed, Sep 9, 2009 at 12:43 AM, Ravi L<moury...@gmail.com> wrote:

> I get 'PM: FS died' error when I boot with new image (with my change).
> And the OS gets stuck.

Just a wild guess, there is something wrong with the process table.
I was also stuck as I could not enlarge it (adding more process entries).
Therefore, there can not be more than 100 processes with the
current MINIX3.

--
Rahmat M. Samik-Ibrahim
VauLSMORG -- http://vlsm.org/

[Evgeniy Ivanov]

On Wed, Sep 9, 2009 at 6:32 AM, Rahmat M. Samik-Ibrahim <rahmatm.sa...@vlsm.org> wrote:

On Wed, Sep 9, 2009 at 12:43 AM, Ravi L<moury...@gmail.com> wrote:

> I get 'PM: FS died' error when I boot with new image (with my change).
> And the OS gets stuck.

Just a wild guess, there is something wrong with the process table.
I was also stuck as I could not enlarge it (adding more process entries).
Therefore, there can not be more than 100 processes with the
current MINIX3.

There should be no problems with enlarging process table. Just be careful with adding (comment in the code points to sconst.h) and building (some things heavily depends on proc structure, so kernel is not the only thing to rebuild). Then you can add new structure members to any place of the structure (begin, middle, end).

--
Evgeniy Ivanov

[Rahmat M. Samik-Ibrahim]

> There should be no problems with enlarging process table. Just be careful
> with adding (comment in the code points to sconst.h) and building (some
> things heavily depends on proc structure, so kernel is not the only thing to
> rebuild). Then you can add new structure members to any place of the
> structure (begin, middle, end).

Have you try it? I tried to increase "#define _NR_PROCS 100"
with no luck. I have reported this problem on 27 June 2009 to
this list with no response. See also;

URL:
http://groups.google.com/group/minix3/browse_thread/thread/2100956fc8fed126

[Evgeniy Ivanov]

By erlarging proc I meant adding new variables. But still changing _NR_PROCS should work too. You didn't describe what happened after you had done it (and what exactly you had done).


--
Evgeniy Ivanov

[Erik van der Kouwe]

Hi Evgeniy,

> By erlarging proc I meant adding new variables. But still changing _NR_PROCS
> should work too. You didn't describe what happened after you had done it
> (and what exactly you had done).

I tried this yesterday (on QEMU/KVM 0.9.1):
- Install 3.1.4-r4817
- Update sources to current from SVN
- make world in /usr/src
- reboot -> works fine
- Modify NR_PROCS to 1000
- make clean world in /usr/src
- reboot -> "Kernel magic number is incorrect" error and the system
does not boot

I think that if the process table grows beyond some size, the boot
loader is no longer capable of locating the magic number in the
kernel. Why this is the case I don't know, I didn't take much time to
debug it

With kind regards,
Erik

[Evgeniy Ivanov]

Well, AFAIK memory between 650K and 1024K is unavailable (used by I/O controller). I would say, that 10x enlarging could be valuable (I thought you speak about 2 or 3 times enlarging). But I doubt it's the reason.



--
Evgeniy Ivanov

[Sys Admin]

I have been looking at the following Minix code in proc_c and can't
understand how it works on multi core systems.

00224 if ( (dst_ptr->p_rts_flags & (RECEIVING | SENDING)) == RECEIVING &&
00225 (dst_ptr->p_getfrom == ANY || dst_ptr->p_getfrom ==
caller_ptr->p_nr)) {
00226 /* Destination is indeed waiting for this message. */
00227 CopyMess(caller_ptr->p_nr, caller_ptr, m_ptr, dst_ptr,
00228 dst_ptr->p_messbuf);
00229 if ((dst_ptr->p_rts_flags &= ~RECEIVING) == 0)
enqueue(dst_ptr);
00230 } else if ( ! (flags & NON_BLOCKING)) {
00231 /* Destination is not waiting. Block and dequeue caller. */
00232 caller_ptr->p_messbuf = m_ptr;
00233 if (caller_ptr->p_rts_flags == 0) dequeue(caller_ptr);
00234 caller_ptr->p_rts_flags |= SENDING;
00235 caller_ptr->p_sendto = dst;
00236
00237 /* Process is now blocked. Put in on the destination's queue.
*/
00238 xpp = &dst_ptr->p_caller_q; /* find end of list */
00239 while (*xpp != NIL_PROC) xpp = &(*xpp)->p_q_link;
00240 *xpp = caller_ptr; /* add caller to end
*/
00241 caller_ptr->p_q_link = NIL_PROC; /* mark new end of
list */

Specifically if the sender and receiver are both running what guarantees
that this code is thread safe

00239 while (*xpp != NIL_PROC) xpp = &(*xpp)->p_q_link;
00240 *xpp = caller_ptr; /* add caller to end
*/

What happens if the receiver chain is modified between lines 239 and 240 ? I
know interrupts are off during a syscall but the receiver could be running
on another hyper thread or core.

Curious ,

Ben

[Erik van der Kouwe]

Hi Ben,

MINIX does not currently support multiple CPUs/cores/hyperthreading,
but this is being worked on.

With kind regards,
Erik

[Tomas Hruby]

> > What happens if the receiver chain is modified between lines 239 and 240 ? I
> > know interrupts are off during a syscall but the receiver could be running
> > on another hyper thread or core.

As Erik pointed out, Minix does not support SMP yet. This code is not
thread safe. Turning off the interrupts work sort of as a lock as the
code cannot be preempted, which in turn means that no other code is
executing. Replacing this by simple locking is not enough though and
the code needs some redesign because some places expect that no other
process is scheduled _anywhere_. It is currently under development,
hopefully available soon.

Cheers, T.

[Sys Admin]

Thanks Erik,

So I'm not being stupid .. Anyway any notes on how the IPC will change ? Im
looking for multiple core Aysnch message parsing IPC implementations that do
minimal or no locking so few around sigh.

Regards,

Ben

[Rahmat M. Samik-Ibrahim]

Evgeniy Ivanov wrote:

>> URL:
>> http://groups.google.com/group/minix3/browse_thread/thread/2100956fc8fed126
> By erlarging proc I meant adding new variables. But still changing _NR_PROCS
> should work too. You didn't describe what happened after you had done it
> (and what exactly you had done).

When I tried this a couple of months ago, I even could not slightly increasing
_NR_PROCS. I have just tried a Minix3 guest again (2 GB RAM size) with
kernel 3.1.4 build 5220 on kubuntu 9.04/vmware-player 2.5.3 build-185404.
I wrote a small program "fo" that forks children to fill the process table.

Test #1: _NR_PROC = 256
There were process table full warnings, but no crashes.

Test #2: _NR_PROC = 386
There were process table full warnings, and many children crashed:
PM: coredump signal 11
VM: pagefault: SIGSEGV badaddr nopage write
BUT NO SYSTEM PANIC.

Test #3: _NR_PROC = 512
The system panic.
M: slaballoc.c:338:slabfree: objstats failed
[...] Panic in forkexit.c