Re: New test kernel - second attempt

[Dennis Clarke <dclarke@blastwave.org>]

On 9/21/25 01:20, Tony Rodriguez wrote:
> “q_work”. Is this queuing based job related ...

It is a stupid dirt simple load test I wrote. It merely tosses out a 
pile of threads and each of those will compute a fibonacci number
while also stuffing numbers into an array on the heap :


    /* thrash heap with calloc foo->array_cnt uint64_t elements */
    foo->big_array = calloc( foo->array_cnt,
                             (size_t)sizeof(uint64_t));

Where foo is a struct :


/* struct to pass params to a POSIX thread */
typedef struct {
  uint32_t  work_num;  /* work order number for a given thread */
  uint64_t *big_array; /* do some work and put data here */
  uint8_t   fibber;    /* horrific fibonacci number computation */
  size_t    array_cnt; /* number of elements to malloc/calloc */
  int       id;        /* thread id number */
} thread_parm_t;


So foo->big_array is a throw away integer array.


    for ( j=0; j<(int)foo->array_cnt; j++ ) {
        *((foo->big_array)+j) = (uint64_t)j
                              + (uint64_t)123456789
                              + (uint64_t)foo->fibber;
    }

The only other thing that the thread will do is compute a fibonacci
number using the most horrible algorithm possible :

k = sprintf(fbuf,"thr %3i : work  %-3i  fib(%-3" PRIu8 ") = %12" PRIu64,
                          thread_id, foo->work_num,
                          foo->fibber, fib(foo->fibber));

puts(fbuf);

That is the total complexity here.

There is a readme file written for students :

    https://git.sr.ht/~blastwave/bw/tree/bw/item/pthread/readme

That is the concept of a queue and then how to toss stuff into a bucket
of "work" and have worker threads pick out the "work" and do something.
In this case the actual work is a fibonacci number wherein the stack get
abused :

https://git.sr.ht/~blastwave/bw/tree/bw/item/pthread/fib.c


uint64_t fib(volatile uint8_t n) <%
    /* This is pure ugly horrific and beautiful in its
     * terrible performance where even a very fast computer
     * will be in deep trouble with any n > 50 and in fact
     * only n=47 is the largest that we have tested.
     * Good luck and you have been warned.
     *
     * Special note : the 64 bit integer limit will be f(92)
     *
     * per bc -l we see
     *
     * scale=32
     * l(7540113804746346429)/l(2)
     * 62.70929200657311058603354483992664
     *
     * So that is just under 2^63 and good luck.
     *
     */
    if ( n == 0 ) <%
        return 0;
    } else if ( n == 1 ) <%
        return 1;
    %> else {
        return ( fib( n - 1 ) + fib( n - 2 ) );
    %>
%>

So that silly bit of code runs *everywhere* and on everything I have
ever tested. Mostly it was of value to explain to some people about the
idea of threads doing things and mutex locks protecting other things.

Now then ... back to the real issue ... how the heck to get the recent
Linux kernel stuff on this machine. That is why I acquired it.  Getting
this thing to boot was a real pain.

I may try to netboot the wheezy install image again just for fun!


--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken