Another one bites the dust - SGI

This is a discussion on Another one bites the dust - SGI ; Alexis Cousein wrote: > Just for a balanced view, I'll add that Linux fans better cut the > hype as well - there are many areas in which IRIX is still miles ahead (VM > management, buffer cache management, NFS,...), ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 64 of 64

Thread: Another one bites the dust

  1. memory management

    Alexis Cousein wrote:
    > Just for a balanced view, I'll add that Linux fans better cut the
    > hype as well - there are many areas in which IRIX is still miles ahead (VM
    > management, buffer cache management, NFS,...), and Linux is not yet the
    > be-all and end-all of operating systems (and can be just as crappy as Solaris



    While I don't claim at all to know anything about linux's memory
    management (except that it somehow manages memory I think), I want
    to point out at least one thing about the irix memory management
    that is both a blessing and an extreme curse at the same time.

    That is that the page size is user settable, through both
    environment variables and dplace. This is a marvelous thing
    because I have a code that speeds up by about a factor of 3.4
    going from 64k pages to 16M pages (see a thread in one of
    the sgi groups from about Jan 2003 or so with me in it--you
    as well). It is a blessing because not many os's have such
    an option available at all. (I've seen a very little discussion
    of hugetlb stuff on lkml, so there is something going on, but
    it is pretty crude afaik)

    It is a curse because it can be **very** difficult to actually
    get these pages allocated to your program, even inside a cpu set
    allocated by pbs, and using dplace. The problem is trying to get
    large pages rather than small pages when you ask for big ones.
    Getting them or not depends on the past memory history of the
    machine and what was running on that memory before you got there,
    which can be anything, with any sort of page fragmentation.

    On the machine I run on, the default page sizes are to have
    95% 16M, 1% 1M and the rest default. What usually happens is
    that lots of fragmentation occurs over the weeks between
    reboots/maintenence days and you get more and more small pages.
    The big pages are difficult to get back. Ever. Even if you
    have (theoretically) sole access permission to run on a certain
    set of memory and cpus, through pbs.

    This can be demonstrated by the following fortran program:

    program bigpage
    c
    c Program to coerce coagulation of small page
    c sizes into larger pages
    c

    integer*8 i4gb
    parameter(i4gb=536800000)
    double precision array(i4gb)
    common/asdf/array !common to avoid stacksize issues

    do i=1,i4gb
    array(i)=0d0
    enddo

    print *,array(42)

    end

    run on the following dplace options (do your own word wrap):

    /usr/sbin/dplace -data_pagesize 16m -data_lpage_wait on
    -stack_pagesize 16m -stack_lpage_wait on a.out

    This very simple program can take 20 minutes or more to run
    because the memory can't get allocated to the right size pages.
    It allocates the first pages to the right ones, but then starts
    to get more and more of the small ones. This can be checked by
    watching top, and using the numa_view command.

    Running it several times gets more and more of the big pages
    (usually 1M, pretty much never 16M), but it still never gets
    back to the original distribution.

    The emphasis here is on the fact that I should theoretically
    have sole access to that bit of memory (4gb), and so should not
    be dealing with anyone else's fragmentation issues. Only the
    past history fragmentation issues that should get resolved
    by running the code above once or twice.


    Sigh.

    Andy



    --
    Andy Nelson School of Mathematics
    andy@maths.ed.ac.uk University of Edinburgh
    http://maths.ed.ac.uk/~andy Edinburgh Scotland EH9 3JZ U. K.

  2. Re: Another one bites the dust

    Alexis Cousein wrote:

    > SkyWriter wrote:
    > >>So you never strictly need to follow a clean-room process to legally reimplement
    > >>copyrighted code, it's just more convinient if the person who owns the copyright
    > >>on the original code throws a hissy-fit.

    > >
    > >
    > > no, having lately given disposition in a patent case;

    >
    > Again: patent != copyright. A patent protects a patentable method (i.e. some
    > subset of what I'd call "ideas"). Copyright only protects specific *expressions*
    > of an idea, and not even *all* expressions of an idea *are* copyrightable.
    >
    > Neither does a clean room protect you from patent infringement. It does protect
    > you from being charged for *willful* infringements (with all the consequences
    > that has on damages that can be recovered from you).
    >


    yes, I know, if you read the thread before admonishing me, you would have read my
    subsequent retraction of my opinion. but that's not what usenet is for is it.

    >
    > --
    > Alexis Cousein Senior Systems Engineer
    > alexis@sgi.com SGI/Silicon Graphics Brussels
    >
    > If I have seen further, it is by standing on reference manuals.



  3. Re: Another one bites the dust

    Alexis Cousein wrote:

    > Tony 'Nicoya' Mantler wrote:
    >
    >> Hamei thinks that just because SGI added code to their linux kernel,
    >> that it instantly has to appear in linus' kernel too or they'd be
    >> breaking the GPL. (which is incorrect)

    >
    >
    > No, that's correct. If it's part of the kernel then it is GPL (see
    > oss.sgi.com).



    Ah -- I see I misread that. It's not because it's GPL that it's accepted
    in Linus's kernel, of course -- as I indicated with my example.

    Another example that is GPL but not accepted in the mainstream kernel
    (as it's replaced by a competing SCSI stack reimplementation
    in the 2.6 kernel -- SGI knew this was going to happen, but couldn't
    wait for the 2.6 kernel to ship Altix) is the xscsi SCSI layer.


    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels

    If I have seen further, it is by standing on reference manuals.


  4. Re: Another one bites the dust

    Alexis Cousein wrote:

    > Just for a balanced view, I'll add that Linux fans better cut the
    > hype as well - there are many areas in which IRIX is still miles ahead
    > (VM
    > management, buffer cache management, NFS,...), and Linux is not yet
    > the
    > be-all and end-all of operating systems



    thanks. Stripped of hyperbole, that was my main intent. Besides that,
    it was nice to see a few posts in this recently-moribund forum :-)

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4