Re: [9fans] 8 cores

Re: [9fans] 8 cores

[Benjamin Huntsman]

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

>coming as no suprise, the pc port of plan 9
>does work just fine with 8 cores.

Just out of interest, what's the machine?

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2320 bytes --]

[9fans] 8 cores

[erik quanstrom]

coming as no suprise, the pc port of plan 9
does work just fine with 8 cores.

mpls; cat /dev/sysstat
          0       14271      213501        3399        1116           0           0           0          99           0
          1        9116      105177        2279         812           0           0           0          99           0
          2       15142      106240        3578        1298           0           0           0          99           0
          3        9529      102845        2663         644           0           0           0          99           0
          4       15035      108986        3717        1285           0           0           0          99           0
          5        9054      105184        2198         744           0           0           0          99           0
          6       15222      106532        3633        1217           0           0           0          99           0
          7        9547      103239        2525         868           0           0           0          99           0

this machine has more processor cache (24mb)
than the entire unix room where i went to school.

and it's only ½ of a 1u chassis.  the other half,
stpaul, has an identical configuration.

- erik

Re: [9fans] 8 cores

[Williams, Mitch]

Which hardware platform is that?
-mlw


-----Original Message-----
From: 9fans-bounces@9fans.net [mailto:9fans-bounces@9fans.net] On Behalf Of erik quanstrom
Sent: Tuesday, July 15, 2008 3:29 PM
To: 9fans@9fans.net
Subject: [9fans] 8 cores

coming as no suprise, the pc port of plan 9 does work just fine with 8 cores.

mpls; cat /dev/sysstat
          0       14271      213501        3399        1116           0           0           0          99           0
          1        9116      105177        2279         812           0           0           0          99           0
          2       15142      106240        3578        1298           0           0           0          99           0
          3        9529      102845        2663         644           0           0           0          99           0
          4       15035      108986        3717        1285           0           0           0          99           0
          5        9054      105184        2198         744           0           0           0          99           0
          6       15222      106532        3633        1217           0           0           0          99           0
          7        9547      103239        2525         868           0           0           0          99           0

this machine has more processor cache (24mb) than the entire unix room where i went to school.

and it's only ½ of a 1u chassis.  the other half, stpaul, has an identical configuration.

- erik

Re: [9fans] 8 cores

[erik quanstrom]

> Which hardware platform is that?
> -mlw

it's a generic xeon 5400-based machine.

- erik

Re: [9fans] 8 cores

[andrey mirtchovski]

add this one to the list:

http://9fans.net/archive/2003/12/182

Re: [9fans] 8 cores

[Benjamin Huntsman]

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

I'd like to ask a question, but before I do, feel I should say, I've been on this list long enough to understand that Plan 9 is a research vessel, not an OS that's targeted at commercial deployment...

That being said, while huge scalability is certainly research-worthy, does anyone actually run anything on Plan 9 that needs or would otherwise benefit from 8+ CPUs and more than a few GB's of RAM?

Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2648 bytes --]

Re: [9fans] 8 cores

[sqweek]

On Wed, Jul 16, 2008 at 1:12 PM, Benjamin Huntsman
<BHuntsman@mail2.cu-portland.edu> wrote:
> That being said, while huge scalability is certainly research-worthy, does anyone actually run anything on Plan 9 that needs or would otherwise benefit from 8+ CPUs and more than a few GB's of RAM?

 The Blue gene HPC folks come to mind.

> Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?

 Some people would like to, but to my knowledge fourth edition hasn't
been ported to any other platforms. I've heard rumors of a near
complete x86_64 port, and there's occasional interest in sparc and ppc
ports.
-sqweek

Re: [9fans] 8 cores

[C H Forsyth]

>Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?

yes: http://tinyurl.com/5jc8u8, for instance

Re: [9fans] 8 cores

[John Waters]

Hi Mr Forsyth,

I tried to respond to your directly, but the mail bounced.
Here in Saudi Arabia tinyurl is blocked (by the govt). Is it possible
that you (or someone else) can expand the URL for me and send it to me
off-list?

Thanks
John Waters,
No relation to the director

On Wed, Jul 16, 2008 at 2:37 PM, C H Forsyth <forsyth@vitanuova.com> wrote:
>>Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
>
> yes: http://tinyurl.com/5jc8u8, for instance
>
>

Re: [9fans] 8 cores

[Russ Cox]

> Some people would like to, but to my knowledge fourth edition hasn't
> been ported to any other platforms.

Plan 9 has always run on multiple architectures,
and the fourth edition is no different.  ls /sys/src/9
will show you that there are ports to the Alpha PC (alphapc)
the HP iPaq (bitsy), and a few PowerPC boards (mtx, ppc).

Russ

Re: [9fans] 8 cores

[a]

For me the URL works out to:

http://domino.research.ibm.com/comm/research_projects.nsf/pages/hare.index.html

HARE! Awesome.
Anthony

Re: [9fans] 8 cores

[erik quanstrom]

> I'd like to ask a question, but before I do, feel I should say, I've
> been on this list long enough to understand that Plan 9 is a research
> vessel, not an OS that's targeted at commercial deployment...

i can't agree with this label "research os" if you mean
to imply that it's not stable or somehow unfinished.

i run the company's infastructure on plan 9 and our main product
— that is my paycheck — depends on plan 9.

i spend a lot less time fixing things now than i did when i
ran a different company's infastructure on aix and linux.
i also suffer much less downtime.

on the other hand, if by "research os" you mean simple
and flexable, then i couldn't agree more.

> That being said, while huge scalability is certainly research-worthy,
> does anyone actually run anything on Plan 9 that needs or would
> otherwise benefit from 8+ CPUs and more than a few GB's of RAM?

this style product will easily scale to that level

	http://tinyurl.com/5e3q9p	[coraid.com]

the real question is can you find a big enough
chassis.

if that doesn't compel you, running upas imap server for ~40 users
with 1.3gb of inboxes might.  since upas has the bad manners to load
the entire mailbox, we're using about 90% of the 3.5gb bios will spare
us in 32bit mode.  i also watched it at 100% cpu for a solid hour
yesterday.

it's embarassing that mail is such a hog.  this is our scalability plan:

	/n/sources/contrib/quanstro/src/nupas/

- erik

Re: [9fans] 8 cores

[Uriel]

> if that doesn't compel you, running upas imap server for ~40 users
> with 1.3gb of inboxes might.  since upas has the bad manners to load
> the entire mailbox, we're using about 90% of the 3.5gb bios will spare
> us in 32bit mode.  i also watched it at 100% cpu for a solid hour
> yesterday.

There is supposedly an amd64 port somewhere which should let you use
more ram, but you already know that. Of course we all also know how
releasing code that people might find useful and even improve is a
crazy idea...

> it's embarassing that mail is such a hog.  this is our scalability plan:
>
>        /n/sources/contrib/quanstro/src/nupas/

Agreed

uriel

Re: [9fans] 8 cores

[Uriel]

You could always import /net from a 9grid node in a (more) free
country ;) (Maybe SA should start filtering 9P connections ;)

Peace

uriel

On Wed, Jul 16, 2008 at 2:13 PM, John Waters <jcwjr215@gmail.com> wrote:
> Hi Mr Forsyth,
>
> I tried to respond to your directly, but the mail bounced.
> Here in Saudi Arabia tinyurl is blocked (by the govt). Is it possible
> that you (or someone else) can expand the URL for me and send it to me
> off-list?
>
> Thanks
> John Waters,
> No relation to the director
>
> On Wed, Jul 16, 2008 at 2:37 PM, C H Forsyth <forsyth@vitanuova.com> wrote:
>>>Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
>>
>> yes: http://tinyurl.com/5jc8u8, for instance
>>
>>
>
>

Re: [9fans] 8 cores

[John Waters]

I have a means to circumvent the filters, but not at my current location.
Thankfully 9p flows as poorly as all the other protocols here in KSA,
but it still flows. I wonder sometimes if I am the only plan 9 user in
"The Kingdom"... Where most folks are accustomed to "five nines" of
availability, the denizens of my hot/dusty/boring city are generally
happy with "five sevens".

Getting back to the topic at hand, does anyone know any specific
8-core capable motherboards that are running plan 9 on bare metal?

ma salaama
jcw

On Wed, Jul 16, 2008 at 4:44 PM, Uriel <uriel99@gmail.com> wrote:
> You could always import /net from a 9grid node in a (more) free
> country ;) (Maybe SA should start filtering 9P connections ;)
>
> Peace
>
> uriel
>
> On Wed, Jul 16, 2008 at 2:13 PM, John Waters <jcwjr215@gmail.com> wrote:
>> Hi Mr Forsyth,
>>
>> I tried to respond to your directly, but the mail bounced.
>> Here in Saudi Arabia tinyurl is blocked (by the govt). Is it possible
>> that you (or someone else) can expand the URL for me and send it to me
>> off-list?
>>
>> Thanks
>> John Waters,
>> No relation to the director
>>
>> On Wed, Jul 16, 2008 at 2:37 PM, C H Forsyth <forsyth@vitanuova.com> wrote:
>>>>Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
>>>
>>> yes: http://tinyurl.com/5jc8u8, for instance
>>>
>>>
>>
>>
>
>

Re: [9fans] 8 cores

[Robert William Fuller]

Uriel wrote:
> You could always import /net from a 9grid node in a (more) free
> country ;) (Maybe SA should start filtering 9P connections ;)
>
> Peace

Glad to hear that device remoting has some practical applications :-)
Given the US Department of Homeland Insecurity, we may need that in the
US soon.  Hopefully, the current regime will die a gruesome political
death in the coming election.

Re: [9fans] 8 cores

[Benjamin Huntsman]

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

>i can't agree with this label "research os" if you mean
>to imply that it's not stable or somehow unfinished.

Not at all.  Just meant that one doesn't run their company's Oracle database on it.
Not because it's not worthy of doing so, but such things just aren't compiled for it.

>...you mean simple and flexable, then i couldn't agree more.

And always trying to find the "right" or most elegant way to do things...


>>Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
>
>yes: http://tinyurl.com/5jc8u8, for instance

Hadn't seen that before.  Anyone know what cluster interface they're using?

Thanks!!
-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2780 bytes --]

Re: [9fans] 8 cores

[Uriel]

On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman
<BHuntsman@mail2.cu-portland.edu> wrote:
>>i can't agree with this label "research os" if you mean
>>to imply that it's not stable or somehow unfinished.
>
> Not at all.  Just meant that one doesn't run their company's Oracle database on it.
> Not because it's not worthy of doing so, but such things just aren't compiled for it.

You might be able to run Oracle with linuxemu... if Firefox runs, anything can!

uriel

Re: [9fans] 8 cores

[Roman V. Shaposhnik]

On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote:
> coming as no suprise, the pc port of plan 9
> does work just fine with 8 cores.
>
> mpls; cat /dev/sysstat
>           0       14271      213501        3399        1116           0           0           0          99           0

Looking at the output 99% is idle time. Have you had a chance to
look at this system when it is fully loaded with something
meaningful?

Thanks,
Roman.

Re: [9fans] 8 cores

[Iruata Souza]

On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman
<BHuntsman@mail2.cu-portland.edu> wrote:
> Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
>

only for the fun of it, I'm slowly trying to port it to my SGI O2.

iru

Re: [9fans] 8 cores

[erik quanstrom]

> On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote:
>> coming as no suprise, the pc port of plan 9
>> does work just fine with 8 cores.
>>
>> mpls; cat /dev/sysstat
>>           0       14271      213501        3399        1116           0           0           0          99           0
>
> Looking at the output 99% is idle time. Have you had a chance to
> look at this system when it is fully loaded with something
> meaningful?

not really.  a kernel compile from ramfs took about 2.9s with an
average of more than 3s of cpu used for every second of real time.  a
compile from the fs over a gigabit link took about 1s longer, but used
far less cpu.

neither is particular impressive, but i'm not using a great percentage
of the cycles available ( ~3/8) and i am using the slowest processor on
the sheet and, due to my misreading of the datasheet, i have only half
the memory channels populated.

did you have anything specific in mind?

- erik

Re: [9fans] 8 cores

[Kernel Panic]

Uriel wrote:
> On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman
> <BHuntsman@mail2.cu-portland.edu> wrote:
>
>>> i can't agree with this label "research os" if you mean
>>> to imply that it's not stable or somehow unfinished.
>>>
>> Not at all.  Just meant that one doesn't run their company's Oracle database on it.
>> Not because it's not worthy of doing so, but such things just aren't compiled for it.
>>
>
> You might be able to run Oracle with linuxemu...
Hmmm... I would doubt it until tried... I could imagine that databases
use mmap() havily
and the mmap() of linuxemu is just a hack that that reads the whole
file-mapping in... and writes
the whole thing out again on msync()... thats one reason the startup
time of firefox is so
slow on linuxemu (besides it makes millions of stats/open/access calls
when starting up)
> if Firefox runs, anything can!
>
I have seen so mutch programs breaking in obscure ways while hacking
linuxemu... sure,
sometimes you are lucky and it just works... but still dont expect too
mutch...
> uriel
>
cinap

Re: [9fans] 8 cores

[Kernel Panic]

Iruata Souza wrote:
> On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman
> <BHuntsman@mail2.cu-portland.edu> wrote:
>
>> Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore?
>>
>>
>
> only for the fun of it, I'm slowly trying to port it to my SGI O2.
>
nice! whats the status of your port? have an SGI indy (IP22) and would
like to
contribute if i find the time :-)

please put it somewhere!
> iru
>
cinap

Re: [9fans] 8 cores

[Charles Forsyth]

> I could imagine that databases use mmap() havily

it's a little mystery for me why they would do that since it's slower (or ought to be),
because the trap path and fault recovery must do more work than syscall (perhaps much more).
it's also difficult then to optimise the replacement strategy for the application
without madvise calls (and you trust those implicitly?) but those are system calls that cost time.

Re: [9fans] 8 cores

[Kernel Panic]

Charles Forsyth wrote:
>> I could imagine that databases use mmap() havily
>>
>
> it's a little mystery for me why they would do that since it's slower (or ought to be),
> because the trap path and fault recovery must do more work than syscall (perhaps much more).
> it's also difficult then to optimise the replacement strategy for the application
> without madvise calls (and you trust those implicitly?) but those are system calls that cost time.
>
>
makes sense of course...

but at least mysql uses mmap() for some table types as a caching mechanism.
http://www.mysqlperformanceblog.com/2006/05/26/myisam-mmap-feature-51/

this may just be an exception and real databases use read()/write() syscalls
and implement the caching themself.

but where should i know... i dont need/use databases and have not looked
at the sourcecode of one.

cinap

Re: [9fans] 8 cores

[Roman V. Shaposhnik]

On Thu, 2008-07-17 at 10:07 +0100, Charles Forsyth wrote:
> > I could imagine that databases use mmap() havily
>
> it's a little mystery for me why they would do that since it's slower (or ought to be),

slower compared to what? I'd expect the biggest slowdown for
read()/write() be not the price of a syscall, but what you
pay for copying data in/out of the kernel. With mmap() there's
no copying.

Thanks,
Roman.

Re: [9fans] 8 cores

[Roman V. Shaposhnik]

On Wed, 2008-07-16 at 22:09 -0400, erik quanstrom wrote:
> > On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote:
> >> coming as no suprise, the pc port of plan 9
> >> does work just fine with 8 cores.
> >>
> >> mpls; cat /dev/sysstat
> >>           0       14271      213501        3399        1116           0           0           0          99           0
> >
> > Looking at the output 99% is idle time. Have you had a chance to
> > look at this system when it is fully loaded with something
> > meaningful?
>
> not really.  a kernel compile from ramfs took about 2.9s with an
> average of more than 3s of cpu used for every second of real time.  a
> compile from the fs over a gigabit link took about 1s longer, but used
> far less cpu.
>
> neither is particular impressive, but i'm not using a great percentage
> of the cycles available ( ~3/8) and i am using the slowest processor on
> the sheet and, due to my misreading of the datasheet, i have only half
> the memory channels populated.

I see.

> did you have anything specific in mind?

Not really, no. Most of the benchmarks that I'm familiar with
would require a strong compiler support which is not (yet?)
available on Plan9. Things like SPEC OMP and the like. I was
looking more for a nice war story, I guess.

Thanks,
Roman.

Re: [9fans] 8 cores

[ron minnich]

On Thu, Jul 17, 2008 at 2:07 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>> I could imagine that databases use mmap() havily
>
> it's a little mystery for me why they would do that since it's slower


Well, depends. Non-mmap you have to do the storage management in the
app. mmap, you're using the storage management in the kernel to figure
out where the data goes, as well as all the LRU stuff to figure out
what happens when you're running out of memory and you need to get rid
of some of it.. Most kernels do a better job than most people at this
sort of thing (at least from code I've seen).

mmap can also reduce memory pressure, since there's only one copy of
the data (for some kernels anyway; others are smarter).

In a number of kernels, the read path for page-aligned page-sized data
is via mmap anyway, so any measurement at that point is going to make
mmap look cheaper. Even the read path is an mmap!

Looking at the Plan 9 exec path it's hard to see a reason that Plan 9
could not do mmap, it just doesn't. But lots of code nowadays depends
on mmap being there. Is there something I'm missing?

ron

Re: [9fans] 8 cores

[William Josephson]

On Thu, Jul 17, 2008 at 05:55:00AM -0700, ron minnich wrote:
> Looking at the Plan 9 exec path it's hard to see a reason that Plan 9
> could not do mmap, it just doesn't. But lots of code nowadays depends
> on mmap being there. Is there something I'm missing?

I think Russ has given this as an exercise to more than
one member of the list in the past :-)

Re: [9fans] 8 cores

[Paweł Lasek]

On Thu, Jul 17, 2008 at 11:07, Charles Forsyth <forsyth@terzarima.net> wrote:
>> I could imagine that databases use mmap() havily
>
> it's a little mystery for me why they would do that since it's slower (or ought to be),
> because the trap path and fault recovery must do more work than syscall (perhaps much more).
> it's also difficult then to optimise the replacement strategy for the application
> without madvise calls (and you trust those implicitly?) but those are system calls that cost time.
>
>
>

A much more important reason might be the fact that memory mapping of
files is only one function of mmap() and company. Basically when you
have mmap() and munmap() you can write your own allocator (which might
be very useful, especially for databases). I won't delve into using it
for I/O, but a specialized memory allocator can get you a big speedup
- after all application developer knows the memory usage pattern of
his app better than kernel/system library.


Of course, that is assuming that the developer in question has a clue...
-- 
Paweł Lasek

Re: [9fans] 8 cores

[erik quanstrom]

> Well, depends. Non-mmap you have to do the storage management in the
> app. mmap, you're using the storage management in the kernel to figure
> out where the data goes, as well as all the LRU stuff to figure out
> what happens when you're running out of memory and you need to get rid
> of some of it.. Most kernels do a better job than most people at this
> sort of thing (at least from code I've seen).

i haven't found this to be the case.

in a former life, one i'd rather forget, i did
full text search.

in order to return the full text, we had to go
get the document.  due to the very crappy
nature of ext2, it was not feasable to store
the documents individually.  they had to
be bundled up in chunks of about 1gb.

being young and easily distracted by shiny
bits, i decided to use mmap.  to my shock
and horror, this turned out to be really slow.
so then i modified the mmap to only map
part of the file.  this was faster, but the
speed of this operation was strongly influenced
by the size of the file.

if i had been even moderately smart, i would
have just read the part of the file i needed.
it would have been much, much faster.

as to using mmap for memory management,
that confuses me.  it's like saying the os should
provide linked lists, because developers can't do
it.  isn't part of the argument here that applications
know better how to manage buffers?

personally, i suspect the reason the unix guys
need mmap, is to support 100mb of shared libraries
for firefox.

if you want mmap, why not start over with
something like multics.  then you can get
rid of the annoying file abstraction all together.

(of course, disagreeing with ken can be a
dangerous business.)

- erik

Re: [9fans] 8 cores

[Kernel Panic]

Paweł Lasek wrote:
> A much more important reason might be the fact that memory mapping of
> files is only one function of mmap() and company. Basically when you
> have mmap() and munmap() you can write your own allocator (which might
> be very useful, especially for databases). I won't delve into using it
> for I/O, but a specialized memory allocator can get you a big speedup
> - after all application developer knows the memory usage pattern of
> his app better than kernel/system library.
>
you can write you own allocator with brk() or
segattach()/segbrk()/segfree() too... the
only things you cant is:

- map on some fixed address
- remap

cinap

Re: [9fans] 8 cores

[ron minnich]

On Thu, Jul 17, 2008 at 6:45 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> i haven't found this to be the case.

it's not always the case.

>
> in a former life, one i'd rather forget, i did
> full text search.
>
> in order to return the full text, we had to go
> get the document.  due to the very crappy
> nature of ext2, it was not feasable to store
> the documents individually.  they had to
> be bundled up in chunks of about 1gb.
>
> being young and easily distracted by shiny
> bits, i decided to use mmap.

A very bad mistake for streaming data.


> as to using mmap for memory management,
> that confuses me.  it's like saying the os should
> provide linked lists, because developers can't do
> it.  isn't part of the argument here that applications
> know better how to manage buffers?
>

In certain cases, the OS memory management for pages can be exploited
and it can do a good job for you. Not in all cases of course.

ron

Re: [9fans] 8 cores

[Roman V. Shaposhnik]

On Thu, 2008-07-17 at 05:55 -0700, ron minnich wrote:
> Looking at the Plan 9 exec path it's hard to see a reason that Plan 9
> could not do mmap, it just doesn't. But lots of code nowadays depends
> on mmap being there. Is there something I'm missing?

I've commented privately to Erik that this is, in fact, what I'm
interested in: using mmap() not as a first-class abstraction,
but as a useful optimization technique in places where it can
speed things up.

Thanks,
Roman.

P.S. Of course, as was pointed out
   (a) speeding things up in one place (read/write) could easily
       slow them down elsewhere in the kernel
   (b) there's no point in lots of RPMs if 99% you're in neutral
and (a) is precisely why I tend to ask question instead
of implementing this stuff up -- I'm just not all that much
of an OS kernel guy to be 100% sure that it will end up
being worth it.

Re: [9fans] 8 cores

[Iruata Souza]

On Thu, Jul 17, 2008 at 5:38 AM, Kernel Panic <cinap_lenrek@gmx.de> wrote:
> Iruata Souza wrote:
>>
>> On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman
>> <BHuntsman@mail2.cu-portland.edu> wrote:
>>
>>>
>>> Furthermore, does anyone out there run Plan 9 on non-x86 hardware
>>> anymore?
>>>
>>>
>>
>> only for the fun of it, I'm slowly trying to port it to my SGI O2.
>>
>
> nice! whats the status of your port? have an SGI indy (IP22) and would like
> to
> contribute if i find the time :-)
>
> please put it somewhere!
>

http://iru.oitobits.net/src/9sgi/
good to know someone's interested besides me and Tim Weiss.

iru

Re: [9fans] 8 cores

[matt]

>> nice! whats the status of your port? have an SGI indy (IP22) and would like
>> to
>> contribute if i find the time :-)
>>
>> please put it somewhere!
>>
>>
> http://iru.oitobits.net/src/9sgi/
> good to know someone's interested besides me and Tim Weiss.
>
> iru
>

Hi, good work

does that mean it works or does that mean it's in progress ?

I see from the mkfile some stuff is commented out so I guess the latter.
I don't have any SGIs (unless you count 1 ps/2 keyboard).

A readme in the folder would be a good idea :)

matt

Re: [9fans] 8 cores

[Iruata Souza]

On Wed, Jul 23, 2008 at 8:42 AM, matt <mattmobile@proweb.co.uk> wrote:
>
>>> nice! whats the status of your port? have an SGI indy (IP22) and would
>>> like
>>> to
>>> contribute if i find the time :-)
>>>
>>> please put it somewhere!
>>>
>>>
>>
>> http://iru.oitobits.net/src/9sgi/
>> good to know someone's interested besides me and Tim Weiss.
>>
>> iru
>>
>
> Hi, good work
>
> does that mean it works or does that mean it's in progress ?
>
> I see from the mkfile some stuff is commented out so I guess the latter.
> I don't have any SGIs (unless you count 1 ps/2 keyboard).
>
> A readme in the folder would be a good idea :)
>
> matt
>
>

it's work in progress.
I commented the bits which are not needed yet in the build process.
the latest code have to be uploaded and the readme is a nice thing to add.

if you want to test, gxemul is a good emulator and is where I do the
testing of minor changes.

thanks,
iru

Re: [9fans] 8 cores

[ron minnich]

On Thu, Jul 17, 2008 at 6:46 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> But you make trips through the vm code on read/write in any event,
>> don't you? There was a pretty good paper comparing these paths once
>> and in the end it boiled down to "your cost will vary depending on how
>> you wrote the kernel" :-)
>
> on plan 9?  where?

I can't remember ...

ron

Re: [9fans] 8 cores

[erik quanstrom]

> But you make trips through the vm code on read/write in any event,
> don't you? There was a pretty good paper comparing these paths once
> and in the end it boiled down to "your cost will vary depending on how
> you wrote the kernel" :-)

on plan 9?  where?

- erik

Re: [9fans] 8 cores

[ron minnich]

On Thu, Jul 17, 2008 at 5:41 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> as you've pointed out, performance-wise it's not copying vs. nothing
> it's copying vs page faults and trips through the vm code.
> i would think playing vm games (as linus likes to say) would make
> scheduling on mp harder
>

But you make trips through the vm code on read/write in any event,
don't you? There was a pretty good paper comparing these paths once
and in the end it boiled down to "your cost will vary depending on how
you wrote the kernel" :-)

This problem has been worked for a long time by Sun among others.
They've had several decades to think on it.

ron

Re: [9fans] 8 cores

[William Josephson]

On Thu, Jul 17, 2008 at 08:41:21AM -0400, erik quanstrom wrote:
> as you've pointed out, performance-wise it's not copying vs. nothing
> it's copying vs page faults and trips through the vm code.
> i would think playing vm games (as linus likes to say) would make
> scheduling on mp harder

Munmap is what is really expensive.  The aio stuff exists
under Unix for Oracle and DB2, which is why it only works
for ordinary files in direct I/O mode under Linux.

 -WJ

Re: [9fans] 8 cores

[erik quanstrom]

> > > I could imagine that databases use mmap() havily
> >
> > it's a little mystery for me why they would do that since it's slower (or ought to be),
>
> slower compared to what? I'd expect the biggest slowdown for
> read()/write() be not the price of a syscall, but what you
> pay for copying data in/out of the kernel. With mmap() there's
> no copying.

as you've pointed out, performance-wise it's not copying vs. nothing
it's copying vs page faults and trips through the vm code.
i would think playing vm games (as linus likes to say) would make
scheduling on mp harder

- erik