openmosix-devel — developers mailing list

[Openmosix-Devel] SMP Safe?

[Gordan B. <go...@bo...>]

Hi,

I only just got back to looking into OpenMosix for clustering, only to 
find out that the project is being EOL-ed. This seems quite disappointing 
now that we are finally on the brink of having a stable and usable GFS 
root file system clustering solution which goes hand-in-hand with what OM 
provides.

I have to say that the reason listed (CPUs getting faster and going 
multi-core) is a bit lame. I don't see why SMP and faster computers should 
somehow preclude clustering. There are always bigger problems to solve, 
and there are always simplifications which were necessary before to 
remove.

On that note, I also noticed that the OM v2.6 kernels are not SMP safe. 
Presumably, neither are the older v2.4 kernels.

My question is - why is OM not SMP safe, and what is required to make it 
SMP safe?

Thanks.

Gordan

[Openmosix-Devel] Kamran is your Yaar! :)

[Kamran <kam...@gm...>]

CjxodG1sPgo8aGVhZD4KPC9oZWFkPgo8Ym9keT4KPHRhYmxlIGFsaWduPSJjZW50ZXIiIHdpZHRo
PSI1NTAiIGhlaWdodD0iMjQ2IgpiYWNrZ3JvdW5kPSJodHRwOi8veWFhcmkuY29tL3ktdmlyYWwv
aW1nL2JveC1hbGwuanBnIj48dHI+PHRkPgogIDxkaXYgaWQ9ImNvbnRhaW5lciIKc3R5bGU9InRl
eHQtYWxpZ246Y2VudGVyO2ZvbnQtZmFtaWx5OlZlcmRhbmEsQXJpYWw7Zm9udC13ZWlnaHQ6Ym9s
ZDtmb250LXNpemU6MTFwdDsiPgogICAgPHRhYmxlIHdpZHRoPSI5NyUiIGhlaWdodD0iOTAlIiBh
bGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLXRvcDoxMHB4OyI+CiAgICAgIDx0ciB2YWxpZ249
Im1pZGRsZSI+CiAgICAgICAgPHRkIHdpZHRoPSIyMCUiPgogICAgICAgICAgPGltZyBzcmM9Imh0
dHA6Ly93d3cueWFhcmkuY29tL3VzZXJfMTAwcHhwaWMvbm9faW1nX2JpZy5qcGciCnN0eWxlPSJk
aXNwbGF5OmJsb2NrO21hcmdpbjphdXRvO21hcmdpbi1ib3R0b206MTBweDtib3JkZXI6bm9uZTsi
IC8+CiAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXNpemU6OXB0O3RleHQtYWxpZ246Y2VudGVy
OyI+S2FtcmFuPC9kaXY+CiAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXNpemU6OXB0O2NvbG9y
OiNCMDA7dGV4dC1hbGlnbjpjZW50ZXI7Ij5SYXdhbHBpbmRpPC9kaXY+CiAgICAgICAgPC90ZD4K
ICAgICAgICA8dGQ+CiAgICAgICAgICA8ZGl2IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjsiPkth
bXJhbiBTb29tcm8gd2FudHMgeW91IHRvIGpvaW4gWWFhcmkhPC9kaXY+CiAgICAgICAgICA8ZGl2
CnN0eWxlPSJmb250LXNpemU6MTNwdDttYXJnaW4tdG9wOjM1cHg7bWFyZ2luLWJvdHRvbToxMHB4
O3RleHQtYWxpZ246Y2VudGVyO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5JcwpLYW1yYW4geW91ciBmcmll
bmQ/PC9kaXY+CiAgICAgICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46MjVw
eDt0ZXh0LWFsaWduOmNlbnRlcjsiPgogICAgICAgICAgICA8YSBocmVmPSJodHRwOi8vd3d3Lnlh
YXJpLmNvbS95LXJlZ2lzdGVyLnBocD9pPThDRkdVQUZJT1FETDc5N0QxMTg2MDc0MDcxIj4KICAg
ICAgICAgICAgICA8aW1nIHNyYz0iaHR0cDovL3lhYXJpLmNvbS95LXZpcmFsL2ltZy9idXR0b24t
eWVzLmdpZiIgYWx0PSJZZXMiCnN0eWxlPSJib3JkZXI6bm9uZTttYXJnaW46MCA1cHg7Ii8+PC9h
PgogICAgICAgICAgICA8YSBocmVmPSJodHRwOi8vd3d3LnlhYXJpLmNvbS95LXJlZ2lzdGVyLnBo
cCI+CiAgICAgICAgICAgICAgPGltZyBzcmM9Imh0dHA6Ly95YWFyaS5jb20veS12aXJhbC9pbWcv
YnV0dG9uLW5vLmdpZiIgYWx0PSJObyIKc3R5bGU9ImJvcmRlcjpub25lO21hcmdpbjowIDVweDsi
IC8+PC9hPgogICAgICAgICAgPC9kaXY+CiAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXNpemU6
OXB0O3RleHQtYWxpZ246Y2VudGVyOyI+UGxlYXNlIHJlc3BvbmQgb3IgS2FtcmFuIG1pZ2h0IHRo
aW5rIHlvdQpzYWlkIG5vIDooPC9kaXY+CiAgICAgICAgPC90ZD4KICAgICAgPC90cj4KICAgIDwv
dGFibGU+CiAgPC9kaXY+CjwvdGQ+PC90cj48L3RhYmxlPgo8cCBhbGlnbj0iY2VudGVyIiBzdHls
ZT0iZm9udC1zaXplOjEwcHQiPgogIDxiciAvPgogIFRvIHN0b3AgcmVjZWl2aW5nIGVtYWlscyBm
cm9tIFlhYXJpLmNvbSwgY2xpY2sgPGEKaHJlZj0iaHR0cDovL3lhYXJpLmNvbS95LWVtYWlsLW9w
dC1vdXQucGhwIj5oZXJlPC9hPi4KICA8YnIgLz4KICBJZiB5b3UgaGF2ZSBhbnkgY29uY2VybnMg
cmVnYXJkaW5nIHRoZSBjb250ZW50IG9mIHRoaXMgbWVzc2FnZSwgcGxlYXNlIGVtYWlsIGFidXNl
QHlhYXJpLmNvbS4KICA8YnIgLz4KICA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjhwdCI+WWFhcmkg
TExDLCAzNTggQW5naWVyIEF2ZSwgQXRsYW50YSwgR0EgCjMwMzEyPC9zcGFuPgo8L3A+CjwvYm9k
eT4KPC9odG1sPgo=

Re: [Openmosix-Devel] [openMosix-general] Openmosix 2.6.22 project still continuing

[Wes W. <wes...@gm...>]

Julia,

That would be great if you could host it and potentially someone else could
pair it up by donating another box. Would you be at all inclined in managing
it from the standpoint of checking it out to openmosix developers for a few
days at a time so they can use it without trampling on each other? An 8 way
box like that would extremely useful to anyone working on validating and
making sure the OM code is SMP safe.

-Wes


On 8/13/07, ri...@vo... <ri...@vo...> wrote:
>
> On Mon, Aug 13, 2007 at 12:28:41PM -0700, Wes Wagner wrote:
> > I have lab space (HVAC + 240V power)  that is SSH accessable in my home
> but
> > that would be a beast... I don't know that we need quite that much
> > horsepower for testing. My lab only has 30 amps of 240 so i try to keep
> most
> > my machine below a half amp of power :)
> >
> > Anyone have any ideas?
> >
> > -Wes
> >
> >
> > On 8/13/07, br...@ca... <br...@ca...> wrote:
> > >
> > >
> > > I have a Dell 8450 8 processor x86 system that I would be happy to
> > > donate.  Unfortunately, it's currently  in the United States.  It's
> very
> > > heavy and would cost a small fortune to ship.  I'm open to
> suggestions...
> > >
> > >
> > >
> > > Bruce Kissinger
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 10 Aug 2007 10:10:49 -0700, "Wes Wagner" <wes...@gm...
> >
> > > wrote:
> > >
> > > > The openmosix 2.6 project is getting new steam. There have been 2
> $100
> > >
> > > > pledges to distribute to the coder(s) (right now it is really just
> > > Florian
> > >
> > > > for the real kernel work) when the successful alpha comes out. Other
> > > items
> > >
> > > > that could help the project is amd64 and i386 test equipment, (procs
> and
> > >
> > > > mbs), for Florian to use in testing. If you have some beat up old
> > >
> > > > equipment
> > >
> > > > that works but you don't need and live in Europe so you can ship it
> > > cheap,
> > >
> > > > please consider donating it to the project.
> > >
> > > >
> > >
> > > > By the end of the weekend we should have everything together enough
> that
> > >
> > > > we
> > >
> > > > can start accepting work from other developers. We have been working
> on
> > >
> > > > the
> > >
> > > > infrastructure needed to support collaboration without anyone
> stepping
> > > on
> > >
> > > > each other's toes.
> > >
> > > >
> > >
> > > > We are also looking to rename the product/project - so name
> suggestions
> > >
> > > > are
> > >
> > > > welcome. I have already had some good ideas proposed but we can use
> some
> > >
> > > > more. Moshe suggested rebranding and Florian and I agree entirely
> that a
> > >
> > > > new
> > >
> > > > name will convey that 2.6 is different than the project objectives
> of
> > > 2.4,
> > >
> > > > and has been significantly rethought in light of the changes in
> market
> > >
> > > > needs
> > >
> > > > and hardware architectures.
> > >
> > > >
> > >
> > > >
> > >
> > >
> >
> >
> > --
> > Wes Wagner
>
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > openMosix-devel mailing list
> > ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>
> some quick googling shows the dell 8450 is a 7U machine. not bad.
>
> where in the US is it located?
>
> i can offer some space in a financial institution's rack. however, i'm
> located in arkansas.
>
> Julia Longtin <ri...@vo...>
>



-- 
Wes Wagner

Re: [Openmosix-Devel] [openMosix-general] Openmosix 2.6.22 project still continuing

[<ri...@vo...>]

On Mon, Aug 13, 2007 at 12:28:41PM -0700, Wes Wagner wrote:
> I have lab space (HVAC + 240V power)  that is SSH accessable in my home but
> that would be a beast... I don't know that we need quite that much
> horsepower for testing. My lab only has 30 amps of 240 so i try to keep most
> my machine below a half amp of power :)
> 
> Anyone have any ideas?
> 
> -Wes
> 
> 
> On 8/13/07, br...@ca... <br...@ca...> wrote:
> >
> >
> > I have a Dell 8450 8 processor x86 system that I would be happy to
> > donate.  Unfortunately, it's currently  in the United States.  It's very
> > heavy and would cost a small fortune to ship.  I'm open to suggestions...
> >
> >
> >
> > Bruce Kissinger
> >
> >
> >
> >
> >
> > On Fri, 10 Aug 2007 10:10:49 -0700, "Wes Wagner" <wes...@gm...>
> > wrote:
> >
> > > The openmosix 2.6 project is getting new steam. There have been 2 $100
> >
> > > pledges to distribute to the coder(s) (right now it is really just
> > Florian
> >
> > > for the real kernel work) when the successful alpha comes out. Other
> > items
> >
> > > that could help the project is amd64 and i386 test equipment, (procs and
> >
> > > mbs), for Florian to use in testing. If you have some beat up old
> >
> > > equipment
> >
> > > that works but you don't need and live in Europe so you can ship it
> > cheap,
> >
> > > please consider donating it to the project.
> >
> > >
> >
> > > By the end of the weekend we should have everything together enough that
> >
> > > we
> >
> > > can start accepting work from other developers. We have been working on
> >
> > > the
> >
> > > infrastructure needed to support collaboration without anyone stepping
> > on
> >
> > > each other's toes.
> >
> > >
> >
> > > We are also looking to rename the product/project - so name suggestions
> >
> > > are
> >
> > > welcome. I have already had some good ideas proposed but we can use some
> >
> > > more. Moshe suggested rebranding and Florian and I agree entirely that a
> >
> > > new
> >
> > > name will convey that 2.6 is different than the project objectives of
> > 2.4,
> >
> > > and has been significantly rethought in light of the changes in market
> >
> > > needs
> >
> > > and hardware architectures.
> >
> > >
> >
> > >
> >
> >
> 
> 
> -- 
> Wes Wagner

> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel

some quick googling shows the dell 8450 is a 7U machine. not bad.

where in the US is it located?

i can offer some space in a financial institution's rack. however, i'm located in arkansas.

Julia Longtin <ri...@vo...>

Re: [Openmosix-Devel] [openMosix-general] Openmosix 2.6.22 project still continuing

[Wes W. <wes...@gm...>]

I have lab space (HVAC + 240V power)  that is SSH accessable in my home but
that would be a beast... I don't know that we need quite that much
horsepower for testing. My lab only has 30 amps of 240 so i try to keep most
my machine below a half amp of power :)

Anyone have any ideas?

-Wes


On 8/13/07, br...@ca... <br...@ca...> wrote:
>
>
> I have a Dell 8450 8 processor x86 system that I would be happy to
> donate.  Unfortunately, it's currently  in the United States.  It's very
> heavy and would cost a small fortune to ship.  I'm open to suggestions...
>
>
>
> Bruce Kissinger
>
>
>
>
>
> On Fri, 10 Aug 2007 10:10:49 -0700, "Wes Wagner" <wes...@gm...>
> wrote:
>
> > The openmosix 2.6 project is getting new steam. There have been 2 $100
>
> > pledges to distribute to the coder(s) (right now it is really just
> Florian
>
> > for the real kernel work) when the successful alpha comes out. Other
> items
>
> > that could help the project is amd64 and i386 test equipment, (procs and
>
> > mbs), for Florian to use in testing. If you have some beat up old
>
> > equipment
>
> > that works but you don't need and live in Europe so you can ship it
> cheap,
>
> > please consider donating it to the project.
>
> >
>
> > By the end of the weekend we should have everything together enough that
>
> > we
>
> > can start accepting work from other developers. We have been working on
>
> > the
>
> > infrastructure needed to support collaboration without anyone stepping
> on
>
> > each other's toes.
>
> >
>
> > We are also looking to rename the product/project - so name suggestions
>
> > are
>
> > welcome. I have already had some good ideas proposed but we can use some
>
> > more. Moshe suggested rebranding and Florian and I agree entirely that a
>
> > new
>
> > name will convey that 2.6 is different than the project objectives of
> 2.4,
>
> > and has been significantly rethought in light of the changes in market
>
> > needs
>
> > and hardware architectures.
>
> >
>
> >
>
>


-- 
Wes Wagner

Re: [Openmosix-Devel] Openmosix 2.6.22 project still continuing

[<ta...@sn...>]

On Fri, Aug 10, 2007 at 10:10:49AM -0700, Wes Wagner wrote:
> We are also looking to rename the product/project - so name suggestions are
> welcome. I have already had some good ideas proposed but we can use some
> more. Moshe suggested rebranding and Florian and I agree entirely that a new
> name will convey that 2.6 is different than the project objectives of 2.4,

That is a good idea, and not only that, but I think a new
name/rebranding/separating from here/.. is totally *mandatory* for
creating a new wave of interested/curious people.

Cheers,
-- 
Vincent Hanquez

Re: [Openmosix-Devel] [Om-2-6-users] Openmosix 2.6.22 project still continuing

[Jonathan D. <im...@ya...>]

In light of, ummmm, some of the more lively? responses
to my posts from earlier, it would be good if we could
work on agreeing a summary of objectives for the
rebranded project.

I'm assuming the shift in user needs will mean that we
add functionality previously considered unnecessary
for a load-balancing system specific to CPU loads.
However, I don't want to get into religious wars over
what should or should not be part of the rebranded
work. I'd much prefer an agreed-upon list of what
users need that we can provide.

I know for a fact that HPC users are positively
screaming for better network support. Cascading
failures and network meltdowns are big issues. I also
know for a fact that the Data Center market is
increasingly unhappy with solutions that have any
single point of failure whatsoever. But are these the
users we are going to be concerned with?

I'll see what non-ix86 hardware I can find, to see how
easy it would be to whip up an experimental (ie: not
in the mainstream OM) port to other platforms, in
addition to whatever projects I already have simmering
that are candidates for putting into the extra
projects.

Since the absolute core code wants to be as
lightweight as possible - for maximum performance,
minimum bugs, etc, it makes little sense to merge
anything not absolutely critical or universal into the
core code, allowing for inevitable special cases and
exceptions.

Since the core shouldn't care one whit about how data
actually arrives or departs, only that it does so in
the times and places expected, I honestly can't think
of any projects of mine - however controversial - that
would have any need or business being in core.

Jonathan

--- Wes Wagner <wes...@gm...> wrote:

> The openmosix 2.6 project is getting new steam.
> There have been 2 $100
> pledges to distribute to the coder(s) (right now it
> is really just Florian
> for the real kernel work) when the successful alpha
> comes out. Other items
> that could help the project is amd64 and i386 test
> equipment, (procs and
> mbs), for Florian to use in testing. If you have
> some beat up old equipment
> that works but you don't need and live in Europe so
> you can ship it cheap,
> please consider donating it to the project.
> 
> By the end of the weekend we should have everything
> together enough that we
> can start accepting work from other developers. We
> have been working on the
> infrastructure needed to support collaboration
> without anyone stepping on
> each other's toes.
> 
> We are also looking to rename the product/project -
> so name suggestions are
> welcome. I have already had some good ideas proposed
> but we can use some
> more. Moshe suggested rebranding and Florian and I
> agree entirely that a new
> name will convey that 2.6 is different than the
> project objectives of 2.4,
> and has been significantly rethought in light of the
> changes in market needs
> and hardware architectures.
> 
> -- 
> Wes Wagner
> >
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? 
> Stop.
> Now Search log events and configuration files using
> AJAX and a browser.
> Download your FREE copy of Splunk now >> 
http://get.splunk.com/>
_______________________________________________
> Om-2-6-users mailing list
> Om-...@li...
>
https://lists.sourceforge.net/lists/listinfo/om-2-6-users
> 



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC

[Openmosix-Devel] Openmosix 2.6.22 project still continuing

[Wes W. <wes...@gm...>]

The openmosix 2.6 project is getting new steam. There have been 2 $100
pledges to distribute to the coder(s) (right now it is really just Florian
for the real kernel work) when the successful alpha comes out. Other items
that could help the project is amd64 and i386 test equipment, (procs and
mbs), for Florian to use in testing. If you have some beat up old equipment
that works but you don't need and live in Europe so you can ship it cheap,
please consider donating it to the project.

By the end of the weekend we should have everything together enough that we
can start accepting work from other developers. We have been working on the
infrastructure needed to support collaboration without anyone stepping on
each other's toes.

We are also looking to rename the product/project - so name suggestions are
welcome. I have already had some good ideas proposed but we can use some
more. Moshe suggested rebranding and Florian and I agree entirely that a new
name will convey that 2.6 is different than the project objectives of 2.4,
and has been significantly rethought in light of the changes in market needs
and hardware architectures.

-- 
Wes Wagner

[Openmosix-Devel] What's going to happen to openmosix 2.6 development effort after Mar-1-2008

[Apollo W. <aw...@gw...>]

Hi all,
What's going to happen to openmosix 2.6 development effort after
Mar-1-2008 when Moshe Bar stop the main openmosix project?
 BTW, is AutoDetect working in 2.6 kernel yet?
Thanks
Apollo
*************************************************************************=
*********************
This email is being sent to you for your information pursuant to your req=
uest. This information is not warranted=20
as to completeness or accuracy. The views expressed in the message are th=
ose of the individual sender,=20
except where the message states otherwise and the sender is authorized to=
 state them to be the views of=20
George Weiss Associates, Inc. or any of its affiliated entities. This mes=
sage is for the named person's use=20
only. It may contain sensitive and private proprietary or legally privile=
ged information. No confidentiality or=20
privilege is waived or lost by any mistransmission. You must not, directl=
y or indirectly, use, disclose, distribute,=20
print or copy any part of this message if you are not the intended recipi=
ent.
*** eSafe scanned this email for viruses, vandals, and malicious content.=
 ***
*************************************************************************=
*********************

[Openmosix-Devel] Work is continuing on openmosix 2.6 w/ Florian

[Wes W. <wes...@gm...>]

Just so everyone generally knows, work has been continuing on
Openmosix 2.6and Florian has been a great help. Somehow I convinced
him to go along with
my crazy idea of releasing 2.6.22 as the first major release instead of
2.6.17. We are concentrating right now on making sure that the development
environment makes it easy for people to collaborate and submit their work. I
am in the process of integrating kgdb into the 2.6.22 line and Florian has
been working on the development environment and wants to get to fixing the
syscall layer as soon as he can.

Our goal for the first 2.6.22 release is to have all basic functionality
working (processes can migrate and make all syscalls) for the i386 and
x86_64 architectures.

If you are interested in continuing to do kernel development work towards
this project, please let me know. So far it seems the only active developer
is Florian so if someone else out there is or has stepped up to the plate I
need to know so I can get you access to the current source repository.

-- 
Wes Wagner

Re: [Openmosix-Devel] 2.6.22 source released on Simple Open Mosix

[Florian D. <fd...@e8...>]

Wes Wagner wrote:
> The 2.6.22 working branch for openmosix 2.6 is available under the simple
> open mosix project on source forge.
>
> https://sourceforge.net/projects/om-2-6/
>
> rsync or checkout from the branches/2.6.22
>
> Inside the scripts directory is a script that will help you apply the
> patches to a vanilla 2.6.22 kernel from kernel.org. This 2.6.22 patch is
> based on the current 2.6.17 source with some modifications. The author of
> omuscd ( http://sourceforge.net/projects/omuscd/ ) was the major contributor
> that made this possible. I just provided some toasty hardware and a little
> moral support :)
>
> i386 and x86_64 are the only supported platforms at this time.
>   

Ok, I'll check that out Friday, and start hacking around :) Thanks for 
the work,

Let's get this project working now

-- 

Florian

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Florian D. <fd...@e8...>]

> Florian, I'll let you be the calm voice in the middle. ;)
>
> I'm not trying to start a war [...]
ok, then, let's get back to work, whenever you want to come back to 
code, please tell me, I'll be glad to answer incoming question (if I can 
at least :) )

> Alright, I'll get down off my soapbox and back to coding. ;)  Glad to hear you 
> now have time to code.  yea!
>   
Well, this weekend should be full of checkins :)

[Openmosix-Devel] 2.6.22 source released on Simple Open Mosix

[Wes W. <wes...@gm...>]

The 2.6.22 working branch for openmosix 2.6 is available under the simple
open mosix project on source forge.

https://sourceforge.net/projects/om-2-6/

rsync or checkout from the branches/2.6.22

Inside the scripts directory is a script that will help you apply the
patches to a vanilla 2.6.22 kernel from kernel.org. This 2.6.22 patch is
based on the current 2.6.17 source with some modifications. The author of
omuscd ( http://sourceforge.net/projects/omuscd/ ) was the major contributor
that made this possible. I just provided some toasty hardware and a little
moral support :)

i386 and x86_64 are the only supported platforms at this time.

-- 
Wes Wagner

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Matt D. <Mat...@se...>]

On Tuesday 31 July 2007 03:16, Florian Delizy wrote:
> > Tab,
> >    The problem is that's all you do.  The only time you speak up on the
> > list is to shoot down others' ideas and tell them they're being stupid.  
> > You're not helpful and you just tell people how they're wrong, without
> > putting out good workable ideas.
>
> Ok, this is no place to start a war you know. Remember Tab is a coder as
> well, and did quite a good job at coding on oM in the early 2.6 version.
> I respect his work as well as his ideas (even if some diplomacy is
> sometime useful to keep working relations with people).

Florian, I'll let you be the calm voice in the middle. ;)

I'm not trying to start a war and I agree that Tab is a good coder and can 
have good ideas. I never said otherwise. Heck, I asked him lots of questions 
when I was working on oM and tried to follow his advice (when he would give 
it).  I'd also love to see him more active on the list.  My problem isn't 
with the lack of diplomacy.  I have a problem when people are quick to shoot 
down others' ideas but keep quiet otherwise, even when they're being asked 
directly for help.    

Yes, I know Moshe was heavily involved in oM on 2.4.  I was around before the 
mosix/oM split and have respect.

As for you not being a project leader. I disagree.  Whomever I see getting in 
and getting their hands dirty ('doing the work' for those not familiar with 
that phrase) , I consider the leader(s).   They are the ones to be followed.  

Alright, I'll get down off my soapbox and back to coding. ;)  Glad to hear you 
now have time to code.  yea!
Matt


>
> > I'd like to know who the project leaders are.  Other than Florian, there
> > doesn't appear to be any.   ?
>
> I am not a leader ... Moshe intend to be (even if he did not code much
> on the 2.6, he coded much on the 2.4 version, correct me if I'm wrong)
> ... till March 2008. Actually I was just a crasy patcher :) who was maid
> maintainer (but who had no time to really hack in the system from
> January now). At least this time is over and I am glad to say that from
> yesterday I do have time now to code on oM (just finished my last 3rd
> job so I have place for oM).
>
> Let's stop those useless and noisy speech, and let's get back to what we
> are aimed to do :
>
> *coding*
>
> and so I will do :)
>
> Tab, Matt, Risc, Whoever want to join back the new coding team.
>
> > Matt
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > openMosix-devel mailing list
> > ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openmosix-devel

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Florian D. <fd...@e8...>]

> Tab, 
>    The problem is that's all you do.  The only time you speak up on the list 
> is to shoot down others' ideas and tell them they're being stupid.   You're 
> not helpful and you just tell people how they're wrong, without putting out 
> good workable ideas.  
>   

Ok, this is no place to start a war you know. Remember Tab is a coder as 
well, and did quite a good job at coding on oM in the early 2.6 version. 
I respect his work as well as his ideas (even if some diplomacy is 
sometime useful to keep working relations with people).
> I'd like to know who the project leaders are.  Other than Florian, there 
> doesn't appear to be any.   ?
>   

I am not a leader ... Moshe intend to be (even if he did not code much 
on the 2.6, he coded much on the 2.4 version, correct me if I'm wrong) 
... till March 2008. Actually I was just a crasy patcher :) who was maid 
maintainer (but who had no time to really hack in the system from 
January now). At least this time is over and I am glad to say that from 
yesterday I do have time now to code on oM (just finished my last 3rd 
job so I have place for oM).

Let's stop those useless and noisy speech, and let's get back to what we 
are aimed to do :

*coding*

and so I will do :)

Tab, Matt, Risc, Whoever want to join back the new coding team.
> Matt
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>
>   

[Openmosix-Devel] Project leads [was: Re: Stubs and wrappers and possibilities, oh my!]

[Matt D. <Mat...@se...>]

Julia,
    Nice to hear from you.   The reason for my question is that I'm just 
wondering who people can directly ask for help and whom to coordinate with.

Patches speak. (to paraphrase Moshe) and not knowing who you can ask for help 
can break a project.  I really want oM to continue so I want to know who the 
leads are.  Sounds like you could be one of them.

Here's my history so people  who  dont' remember don't get the idea I'm just 
talking out of my butt.  For several months late last year I put in a fair 
amount of work on oM.  I started the kcomd code and had it working (very 
roughly), save crashing on (some) syscalls.  Most of that work only took a 
couple weeks and the rest of the time I was trying to track down the syscall 
crash problem.

 I believe Florian has replaced most of my work as it wasn't all that great 
but I put in quite a bit of work over those 3 months.  So I think I'm 
entitled to my opinions too. ;)

Matt



On Monday 30 July 2007 16:12, ri...@vo... wrote:
> On Mon, Jul 30, 2007 at 03:43:18PM -0600, Matt Dew wrote:
> > On Monday 30 July 2007 09:02, Vincent Hanquez wrote:
> > > On Mon, Jul 30, 2007 at 04:52:28PM +0200, Florian Delizy wrote:
> > > > Well, not being that aggressive, that was at least an "idea" (even if
> > > > I agree with you).
> > > >
> > > > BTW, please tab, don't be that agressive when you post replies you
> > > > know, you really don't have to :)
> > >
> > > I'm calling a spade a spade when it's necessary. I'm beeing honest
> > > here, at the expense of any diplomacy obviously.
> >
> > Tab,
> >    The problem is that's all you do.  The only time you speak up on the
> > list is to shoot down others' ideas and tell them they're being stupid.  
> > You're not helpful and you just tell people how they're wrong, without
> > putting out good workable ideas.
> >
> > I'd like to know who the project leaders are.  Other than Florian, there
> > doesn't appear to be any.   ?
> >
> > Matt
>
> I've kinda been waiting for an oportunity to speak up, i guess now is as
> good as any.
>
> I've been working with (more watching) flordian on bug tracking the code in
> SVN. I've also pushed a patch to svn to clean up some of the cruft and
> non-compiling code that was already there.
>
> working 80 hours a week (or more!) dosent leave me with much OM related
> time, but I see that changing soon. (as soon as i can get my QEMU patches
> worked into upstream)..
>
> for what its worth, i havent spoken up, due to my belief that when people
> have something to contribute, thats usually backed by patches. anything
> else just classifies as noise.
>
> I've commited some patches, so I think I am at least entitled to that much
> opinion. ;)
>
> Julia Longtin <ri...@vo...>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Moshe B. <mo...@gm...>]

Patches definitely speak volumes.

As to your question, Matt, according to our announcement I will lead
the project until March 1, 2008. At that point we'll see if the flurry
of mailing list messages and good intentions result in a new life for
openMosix and then I will be glad to pass it on to the new leader.

Moshe



On 7/30/07, ri...@vo... <ri...@vo...> wrote:
> On Mon, Jul 30, 2007 at 03:43:18PM -0600, Matt Dew wrote:
> >
> > On Monday 30 July 2007 09:02, Vincent Hanquez wrote:
> > > On Mon, Jul 30, 2007 at 04:52:28PM +0200, Florian Delizy wrote:
> > > > Well, not being that aggressive, that was at least an "idea" (even if I
> > > > agree with you).
> > > >
> > > > BTW, please tab, don't be that agressive when you post replies you know,
> > > > you really don't have to :)
> > >
> > > I'm calling a spade a spade when it's necessary. I'm beeing honest here,
> > > at the expense of any diplomacy obviously.
> >
> > Tab,
> >    The problem is that's all you do.  The only time you speak up on the list
> > is to shoot down others' ideas and tell them they're being stupid.   You're
> > not helpful and you just tell people how they're wrong, without putting out
> > good workable ideas.
> >
> > I'd like to know who the project leaders are.  Other than Florian, there
> > doesn't appear to be any.   ?
> >
> > Matt
> >
>
> I've kinda been waiting for an oportunity to speak up, i guess now is as good as any.
>
> I've been working with (more watching) flordian on bug tracking the code in SVN.
> I've also pushed a patch to svn to clean up some of the cruft and non-compiling code that was already there.
>
> working 80 hours a week (or more!) dosent leave me with much OM related time, but I see that changing soon. (as soon as i can get my QEMU patches worked into upstream)..
>
> for what its worth, i havent spoken up, due to my belief that when people have something to contribute, thats usually backed by patches. anything else just classifies as noise.
>
> I've commited some patches, so I think I am at least entitled to that much opinion. ;)
>
> Julia Longtin <ri...@vo...>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[<ri...@vo...>]

On Mon, Jul 30, 2007 at 03:43:18PM -0600, Matt Dew wrote:
> 
> On Monday 30 July 2007 09:02, Vincent Hanquez wrote:
> > On Mon, Jul 30, 2007 at 04:52:28PM +0200, Florian Delizy wrote:
> > > Well, not being that aggressive, that was at least an "idea" (even if I
> > > agree with you).
> > >
> > > BTW, please tab, don't be that agressive when you post replies you know,
> > > you really don't have to :)
> >
> > I'm calling a spade a spade when it's necessary. I'm beeing honest here,
> > at the expense of any diplomacy obviously.
> 
> Tab, 
>    The problem is that's all you do.  The only time you speak up on the list 
> is to shoot down others' ideas and tell them they're being stupid.   You're 
> not helpful and you just tell people how they're wrong, without putting out 
> good workable ideas.  
> 
> I'd like to know who the project leaders are.  Other than Florian, there 
> doesn't appear to be any.   ?
> 
> Matt
> 

I've kinda been waiting for an oportunity to speak up, i guess now is as good as any.

I've been working with (more watching) flordian on bug tracking the code in SVN.
I've also pushed a patch to svn to clean up some of the cruft and non-compiling code that was already there.

working 80 hours a week (or more!) dosent leave me with much OM related time, but I see that changing soon. (as soon as i can get my QEMU patches worked into upstream)..

for what its worth, i havent spoken up, due to my belief that when people have something to contribute, thats usually backed by patches. anything else just classifies as noise.

I've commited some patches, so I think I am at least entitled to that much opinion. ;)

Julia Longtin <ri...@vo...>

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Matt D. <Mat...@se...>]

On Monday 30 July 2007 09:02, Vincent Hanquez wrote:
> On Mon, Jul 30, 2007 at 04:52:28PM +0200, Florian Delizy wrote:
> > Well, not being that aggressive, that was at least an "idea" (even if I
> > agree with you).
> >
> > BTW, please tab, don't be that agressive when you post replies you know,
> > you really don't have to :)
>
> I'm calling a spade a spade when it's necessary. I'm beeing honest here,
> at the expense of any diplomacy obviously.

Tab, 
   The problem is that's all you do.  The only time you speak up on the list 
is to shoot down others' ideas and tell them they're being stupid.   You're 
not helpful and you just tell people how they're wrong, without putting out 
good workable ideas.  

I'd like to know who the project leaders are.  Other than Florian, there 
doesn't appear to be any.   ?

Matt

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Moshe B. <mo...@gm...>]

As the French say (they really invented this saying)

"c'est le ton qui fait la musique".

Diplomacy, I am sure we all agree, and a good, friendly tone in
mailing lists goes a long way to make things happen.

Generally, the rule is don't say or do anything online that you
wouldn't do in presence.

Moshe


On 7/30/07, Vincent Hanquez <ta...@sn...> wrote:
> On Mon, Jul 30, 2007 at 04:52:28PM +0200, Florian Delizy wrote:
> > Well, not being that aggressive, that was at least an "idea" (even if I
> > agree with you).
>
> > BTW, please tab, don't be that agressive when you post replies you know,
> > you really don't have to :)
>
> I'm calling a spade a spade when it's necessary. I'm beeing honest here,
> at the expense of any diplomacy obviously.
>
> --
> Vincent Hanquez
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> openMosix-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
>

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[<ta...@sn...>]

On Mon, Jul 30, 2007 at 04:52:28PM +0200, Florian Delizy wrote:
> Well, not being that aggressive, that was at least an "idea" (even if I 
> agree with you).

> BTW, please tab, don't be that agressive when you post replies you know, 
> you really don't have to :)

I'm calling a spade a spade when it's necessary. I'm beeing honest here,
at the expense of any diplomacy obviously.

-- 
Vincent Hanquez

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[Florian D. <fd...@e8...>]

Vincent Hanquez wrote:
> On Wed, Jul 25, 2007 at 01:54:39PM -0700, Jonathan Day wrote:
>   
>
>> What about kernel threads? Again, same thing applies.
>> We're not short of methods. Everything from HA
>> solutions to suspend-to-file would allow you to
>> transfer kernel-level operations from one machine to
>> another without problem.
>>     
>
> if you're actually talking about freezing kernel thread, it's not
> realistic. actually linux kernel developers are removing the cooperation
> with the suspend freezer right now (2.6.23) which going to be trickier.
> Plus a kernel thread has load of private stuff that CANNOT be migrated
> and tight to the OS.
>   

I agree tab on that point, I see no interest at all in migrating kernel 
threads anyway.


>> Is there anything significant that's needed that's
>> new? Well, the stub should export to userspace any
>> information needed to perform migration and perhaps
>> resource allocation. At the meeting, we thought about
>> various strategies for this. /proc and /sys were
>> suggested, as was using a page of shared memory. I'd
>> love to hear other people's thoughts on this.
>>     
>
> migration passing by userspace process is possible for sending data, but
> that's opening a whole can of worms for other communication (syscalls
> for example).
>   

point, I agree as well, migration should stay in kernel mode, not in 
userspace
>
>> This ends the reading of the stub.
>>     
>
> Except reading random crazy ideas, I don't see the shadow of a solid
> proposal on what to do. This proposal is far too generic (and crazy) and
> doesn't propose any solutions..
>
>   

Well, not being that aggressive, that was at least an "idea" (even if I 
agree with you).

BTW, please tab, don't be that agressive when you post replies you know, 
you really don't have to :)

Re: [Openmosix-Devel] Proposal for CORE components

[<ta...@sn...>]

On Wed, Jul 25, 2007 at 03:21:13PM -0700, Jonathan Day wrote:
> Here is my proposal for the CORE segment of the code.
> The CORE segment is going to be the relatively stable
> component of the code. Code in CORE would exist in two
> states: viscous and locked-down.
> 
> Viscous code would be code that is still changing -
> it's still partly fluid - but changes relatively
> slowly and only as needed. Glue layers between the
> kernel and the CORE would be permanently viscous, as
> the kernel's internal API is designed to change. The
> initial drop into code would be entirely viscous.
> 
> Locked-down code would be code where there is
> sufficient confidence in it being complete and
> sufficient for the current kernel AND in it being as
> stable as can reasonably be achieved. Code should not
> be marked as locked-down unless there's high
> confidence in it. By implication, modifying
> locked-down code should be avoided if possible, and on
> modification it reverts to being viscous.
> 
> The general concept is that the "real work" is largely
> independent of implementation specifics of how the
> data is passed in or out, that the CORE should only do
> the generic, basic "real work" anyway, and that
> everything else (ie: all the heavy lifting, the fancy
> methods, experimental projects and the other code
> that's going to be tough to write) can be attached
> either directly to the viscous interface or to another
> project if you need further abstraction.
> 
> At this point, I simply do not know what would be
> needed in the CORE component. Greater minds than mine,
> however, exist on this list and can undoubtedly give a
> clearer answer to this.
> 
> I imagine that fundamental architecture-specific code
> would reside in there - at least for architectures
> that are actively-enough maintained that the code
> could be viscous or locked-down. I imagine
> universally-required helper functions would be there
> too, but I'll leave that to the true kernel gurus here
> to rule upon.

This is by far the most vague proposal ever...
you're proposing code to do stuff (not really clear what) that need to
be locked-down (probably to do an API), and yet some viscous code
to cope with linux evolution ...

so in a nutshell, "creating an API on linux". why do that need to be
describe in greater than 40 lines ?

-- 
Vincent Hanquez

Re: [Openmosix-Devel] Proposal for accelerating SIMD setups

[<ta...@sn...>]

On Wed, Jul 25, 2007 at 02:26:14PM -0700, Jonathan Day wrote:
> This is a very short (for me) writeup on a proposal
> for accelerating process migration for SIMD-style
> applications. It will NOT be useful for MIMD or
> general-purpose clustering.

SIMD-style application ?

SIMD = single instruction, multiple data

I can see how an application can be using SIMD instructions, and be an
"SIMD application", but what are you accelerating that it is not at the
moment ?

-- 
Vincent Hanquez

Re: [Openmosix-Devel] Stubs and wrappers and possibilities, oh my!

[<ta...@sn...>]

On Wed, Jul 25, 2007 at 01:54:39PM -0700, Jonathan Day wrote:
> One of the things examined was the use of a stub that
> was not migratable between nodes. I was asked to write
> a short piece describing a proposed modification to
> this, so here it is. Note that suggestions, comments
> and clue-stick beatings are welcome, but if you could
> pad the clue-stick a little, I'd be grateful.
> 
> Brief Synopsis: Linux offers a bazillion features,
> network engineers have written a bazillion others. The
> I/O-side stub, as it is, works great but there may be
> ways to make it more powerful and/or faster. We should
> consider if this would be a useful/good thing to do,
> and if so what our priorities should be.
> 
> 
> My suggestion is to first extend the stub. Linux has a
> whole host of new features which should expand the
> usefulness of the stub, and it would be good to
> discuss what we'd want the stub to actually do.
> 
> The second step I proposed was to allow the stub to
> migrate. If the stub migrates, then all user-side I/O
> would migrate with it to the new node, which must
> (therefore) support the same I/O features as are being
> used. So long as the information is available, I don't
> see that being a problem.

Are you understanding why the stubs are not migratable ?

> (By migrating the stub rather than just the data, you
> carry all of the process state, security/permission
> labels, etc, for free and you can reuse existing
> code.)
>
> The problem lies in how to migrate the stubs safely
> and maintain contact with the controlled process,
> without adding any security complications and with
> taking into account any data sent by the process
> during the migration.
> 
> Linux - after applying a couple of patches - provides
> methods for supporting the failover of network
> connections, transient addressing, network mobility,
> kernel-level switching for layers 2, 3, 4 and 7, and
> virtual network devices. In short, we have so many
> ways of getting a connection to switch that it's more
> a case of what method we should use rather than
> whether we can do it.
> 
> A worthy place to look for inspiration is the research
> that has gone into IPv6 mobility. The current version
> uses a transient home base that all connections link
> to. The home base then talks to the user node. When
> the user node moves, a redirect is sent through the
> network. Any connection not yet redirected bounces off
> the home base to wherever the user is. Redirected
> connections go directly to the user. Depending on the
> version of the mobility draft, once all connections
> are redirected, the user becomes the new home base and
> the old home base is closed down.

Now this is really getting into a joke right ?
IPv6 mobility is not a solution to any problem.
an IP/IPv6 is an OS ressource, that can be multiplex (ports)
across all the processes over the OS.

> Alternatively, why keep track at all? Have a
> process-side stub that listens for anycasts. When the
> user-side stub migrates, it sends out an anycast
> request for the UPID it was connected to. The process'
> stub will be the only one to respond, so the
> connection can then be restored.

right so, you are putting a "process side stub" that listen for
anycast to replace the stub, so that the stub can migrate..
look like to me the stubs is actually STAYING to do that, you're just
replacing one stub by another one that does the same thing.

> What about kernel threads? Again, same thing applies.
> We're not short of methods. Everything from HA
> solutions to suspend-to-file would allow you to
> transfer kernel-level operations from one machine to
> another without problem.

if you're actually talking about freezing kernel thread, it's not
realistic. actually linux kernel developers are removing the cooperation
with the suspend freezer right now (2.6.23) which going to be trickier.
Plus a kernel thread has load of private stuff that CANNOT be migrated
and tight to the OS.

> Is there anything significant that's needed that's
> new? Well, the stub should export to userspace any
> information needed to perform migration and perhaps
> resource allocation. At the meeting, we thought about
> various strategies for this. /proc and /sys were
> suggested, as was using a page of shared memory. I'd
> love to hear other people's thoughts on this.

migration passing by userspace process is possible for sending data, but
that's opening a whole can of worms for other communication (syscalls
for example).

> I also suggested that since Linux now supports
> real-time and that time-slicing is much more
> predictable under new scheduler, we might want to
> consider all processes under the control of OpenMosix
> as real-time. Each process then has a fixed-sized
> bucket of time, and the scheduler can use a
> conventional packing herustic to pack those buckets
> into the cluster.

hmm ? the processes are correctly tight to the linux scheduler, thanks
you very much. I don't know why are you talking about real-time, since it's
obviously a per process "state". What are you winning by giving
real-time to all tasks and opening a really bad remote Denial-of-Service ?

> How is this better than using, say, the load average?
> The load average doesn't tell you what's taking the
> time or why, or whether the remaining time is usable.
> (I'm not certain how much you can fragment the block
> of time that the new scheduler uses to timeslice, but
> I can be pretty certain that any desktop system is
> going to have enough events to fragment the time
> block, leaving unusable chunks.)
> 
> Ok, so we want to export the timeslice requirements.
> What else? Any universal ID would be good to export,
> along with what machine the process is running on. We
> also need to export memory tags, as RDMA should not be
> done in the kernel.
> 
> Why not export everything? Because 99% of what is on
> the stub is strictly for I/O to other kernel-based
> components. Very little is needed or wanted by
> userspace, and the less you have to copy, track or
> update, the less latency you'll suffer and the lower
> your requirements. You also get better security.
> 
> This ends the reading of the stub.

Except reading random crazy ideas, I don't see the shadow of a solid
proposal on what to do. This proposal is far too generic (and crazy) and
doesn't propose any solutions..

-- 
Vincent Hanquez