Re: [9fans] 8 cores - Plan9

This is a discussion on Re: [9fans] 8 cores - Plan9 ; > 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 ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Re: [9fans] 8 cores

  1. Re: [9fans] 8 cores

    > 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



  2. Re: [9fans] 8 cores

    > 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


  3. Re: [9fans] 8 cores

    Uriel wrote:
    > On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman
    > 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



  4. Re: [9fans] 8 cores

    > 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.



  5. Re: [9fans] 8 cores

    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/...ap-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



  6. Re: [9fans] 8 cores


    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.



  7. Re: [9fans] 8 cores

    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 :-)


  8. Re: [9fans] 8 cores

    On Thu, Jul 17, 2008 at 2:07 AM, 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



    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


  9. Re: [9fans] 8 cores

    On Thu, Jul 17, 2008 at 6:45 AM, erik quanstrom 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


  10. Re: [9fans] 8 cores

    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



  11. Re: [9fans] 8 cores

    > 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



  12. Re: [9fans] 8 cores

    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.



+ Reply to Thread