Re: ndiswrapper and GPL-only symbols redux
> > > IANAL, and I would therefore ask a lawyer whether, and if yes under > > > which circumstances, shipping a binary driver written for another OS > > > dynamically linked into the Linux kernel would not be a criminal offense. > > > > Please stop throwing around words like "criminal". If this is in fact > > illegal it would be a civil matter. > > You are living in a country where copyright violations can't bring > people into jail? AFAICS you are misunderstanding the words "criminal" and "civil matter". AFAIK in german law the difference between the two is that "criminal" offences are prosecuted by the government out of their own accord while "civil matters" require someone else to sue. Murder and robbery are criminal offences. Assuming the above is correct then copyright violations definitely are "civil matters" in germany regardless whether you could go into jail or not. Best, Michael -- Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.23.13]
This patch does not apply to a clean 2.6.23.13 tree using either of patch -p1 signature.asc Description: This is a digitally signed message part.
Re: OT: Does Linux have any "Perfect Code"
> This code is far to be perfect, some part is outdated, bcopy() use instead
> of memcpy() for example. More annoying are the comment, the file is 3306
> lines while there is only 1640 line of code, nothing bad per se but looking
> some comments:
>
> /*
>* Before we begin this operation, disable kernel preemption.
>*/
> kpreempt_disable();
>
>
> uhh...
>
> or
>
> if (cyclic->cy_pend != 0) {
> /*
>* The pend is non-zero; ...
>
> I will never guessed that, w/o the comment :)
I'm not a kernel developer.
That having said:
I really do like such obvious (as in: for those knowing the stuff anyway)
comments when looking at code and probably concepts I'm not familiar with.
IMO there is no need to belittle this type of comment. IMO any casual
reader not familiar with the whole set of functions possibly involved
will be thankful for this type of comment - I certainly am.
> /*
>* We have both a left and a right child. We need to compare
>* the expiration times of the children to determine which
>* expires earlier.
>*/
> if (cyclics[right].cy_expire < cyclics[left].cy_expire) {
>
> writing array[index] in C is already a promise than index is in
> [0-array size)
Yes. And ?
FWIW whenever I tried to look at kernel code I'm usually facing the
decision to
- either give up trying to understand what is intended or
- do a thorough search to learn everything required
I usually give up due to time constraints.
I mean, isn't the whole purpose of comments to help those not familiar
with the code to understand it's purpose and possibly the intention of
the author (just in case the author had coded a bug) ?
From my PoV this establishes a steep learning curve for "outsiders" to
start working on the kernel.
[just in case: don't give me anything along the line "this is an inherent
test as to the fitness of the potential hacker" ;]
Just my thoughts,
Michael
--
Vote against SPAM - see http://www.politik-digital.de/spam/
Michael Gerdau email: [EMAIL PROTECTED]
GPG-keys available on request or at public keyserver
signature.asc
Description: This is a digitally signed message part.
2.6.23-rc6-mm1 and acpi
Hi, while trying to compile 2.6.23-rc6-mm1 I came across the following build error: [EMAIL PROTECTED]:/usr/src/linux-2.6.23-rc6-mm1> make modules CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh :1389:2: warning: #warning syscall revokeat not implemented :1393:2: warning: #warning syscall frevoke not implemented CC [M] drivers/acpi/sbs.o drivers/acpi/sbs.c: In function ‘acpi_battery_alarm_show’: drivers/acpi/sbs.c:457: error: implicit declaration of function ‘acpi_battery_get_alarm’ drivers/acpi/sbs.c: In function ‘acpi_battery_alarm_store’: drivers/acpi/sbs.c:472: error: implicit declaration of function ‘acpi_battery_set_alarm’ drivers/acpi/sbs.c: In function ‘acpi_battery_add’: drivers/acpi/sbs.c:829: warning: ignoring return value of ‘device_create_file’, declared with attribute warn_unused_result make[2]: *** [drivers/acpi/sbs.o] Fehler 1 make[1]: *** [drivers/acpi] Fehler 2 make: *** [drivers] Fehler 2 Not sure who to CC, which is why I send it to the list alone. Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: 2.6.22.2-cfs-v19.1 stops honouring nice 3 after some hours
> > I played a bit with renicing my (mostly) CPU bound jobs and found > > somewhat strange behaviour. > > > > I'm on 2.6.22.2-cfs-v19.1 -- I can't boot into 2.6.23-rc3 as part of > > my daily work because my NVIDIA driver doesn't yet work with it though > > I could try to do some X-less testing if need be. > > Please do try, a lot has changed since v19.1. Meanwhile I've done some testing on 2.6.23-rc3. The good news is that the strange behaviour w/r to nice I had seen on 2.6.22.3-cfs-v19.1 is no longer there. Long running CPU bound jobs at different nice levels do indeed progress (roughly) according to the %CPU figures as reported by top now. However what I find somewhat unexpected is the IMO huge variation in %CPU as observed even with 'top -d 60'. I've attached a log showing 5 CPU bound tasks observed for an our with 'top -b -d 60 -n 60'. Jobs 5897, 5928 and 5977 do perform essentially the same tasks. Jobs 17085 and 21492 do perform essentially the same task but differ from the other 3 task. I would have expected Jobs 5897 and 5928 to differ by at most one percent point when measured for 60 seconds. Best, Michael -- Technosis GmbH, Geschäftsführer: Heiko Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver top2.log.bz2 Description: BZip2 compressed data signature.asc Description: This is a digitally signed message part.
Re: 2.6.22.2-cfs-v19.1 stops honouring nice 3 after some hours
> > I'm on 2.6.22.2-cfs-v19.1 -- I can't boot into 2.6.23-rc3 as part of > > my daily work because my NVIDIA driver doesn't yet work with it though > > I could try to do some X-less testing if need be. > > Please do try, a lot has changed since v19.1. > > FWIW the nv driver lets one do most desktop-ish things without problems, > or so I've been told - just no 3d. Damien Wyart was kind enough to point me to a patch that solved the compile problem of the nv driver and I now have a ready-to-boot-into 2.6.23-rc3 lying around. However due to other time constraints this will have to wait until tomorrow. Anyway, observing the currently running CPU bound jobs and comparing their progress (as documented by their logfiles) with the CPU % one of the jobs receives (as documented by top -d 60) it seems as if this is not so much a scheduling problem but an accounting issue. FWIW the jobs doing basically the same work are more or less head to head after 12+ hours of computation while according to top one of them is reported to receive roughly twice the CPU of the other. I will retry with 2.6.23-rc3 tomorrow and over the weekend to see whether the problem persists. Best wishes, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ !tagline Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
2.6.22.2-cfs-v19.1 stops honouring nice 3 after some hours
Hi Ingo, I played a bit with renicing my (mostly) CPU bound jobs and found somewhat strange behaviour. I'm on 2.6.22.2-cfs-v19.1 -- I can't boot into 2.6.23-rc3 as part of my daily work because my NVIDIA driver doesn't yet work with it though I could try to do some X-less testing if need be. I'm running 4 CPU bound jobs, 2 of which are more important to me. I therefor reniced the other 2 to level 3 and the CPU percentages were roughly 66/66/33/33 on my Dualcore system. So far all fine. Some 6 hours later I rechecked with top -d 60 and got the output below: 19629 mgd 20 0 334m 263m 2700 R 49 8.1 69:16.45 perl 29668 mgd 20 0 396m 262m 2700 R 49 8.0 112:17.21 perl 6933 mgd 23 3 96576 21m 3672 R 47 0.7 46:38.83 perl 14162 mgd 23 3 165m 28m 3672 R 47 0.9 194:55.31 perl I reniced to 0: 19629 mgd 20 0 334m 263m 2700 R 48 8.1 71:02.86 perl 6933 mgd 20 0 96652 21m 3672 R 48 0.7 48:23.41 perl 14162 mgd 20 0 165m 28m 3676 R 48 0.9 196:39.81 perl 29668 mgd 20 0 396m 262m 2700 R 48 8.0 114:03.56 perl ...and back to 3 with no noticeable change. [at this point job 14162 finished and was replaced by an similar job 22558] I then decided to do some statistics and reniced to 1: 29668 mgd 20 0 396m 262m 2700 R 48 8.0 115:24.12 perl 19629 mgd 20 0 334m 263m 2700 R 48 8.1 72:23.36 perl 22558 mgd 21 1 92184 17m 3672 R 48 0.5 0:56.81 perl 6933 mgd 21 1 96576 21m 3672 R 48 0.7 49:54.12 perl Now I reniced to 2 and without knowing why, the ratios seem to be back to where I want them. 29668 mgd 20 0 396m 262m 2700 R 59 8.0 116:33.98 perl 19629 mgd 20 0 334m 264m 2700 R 58 8.1 73:31.49 perl 22558 mgd 22 2 92220 17m 3672 R 37 0.5 1:46.99 perl 6933 mgd 22 2 96688 21m 3672 R 36 0.7 50:44.77 perl Renicing to 3 again gives me what I want: 29668 mgd 20 0 397m 262m 2700 R 65 8.0 117:25.93 perl 19629 mgd 20 0 334m 264m 2700 R 63 8.1 74:21.84 perl 22558 mgd 23 3 92220 17m 3672 R 32 0.5 2:13.83 perl 6933 mgd 23 3 96652 21m 3672 R 32 0.7 51:11.24 perl I don't know why I had the very first output above though. Best, Michael -- Technosis GmbH, Geschäftsführer: Heiko Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: v2.6.22.1-rt1
> > > to build a 2.6.22.1-rt1 tree, the following patches should be applied: > > > > > > http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2 > > > http://redhat.com/~mingo/realtime-preempt/patch-2.6.22.1-rt1 > > > > I get a compile error on my x86_64 dualcore sytem. > > could you check it builds fine with -rt2? It builds fine now with -rt2. Thanks, best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: v2.6.22.1-rt1
[sorry Ingo for the dublicated post] > to build a 2.6.22.1-rt1 tree, the following patches should be applied: > > http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2 > http://redhat.com/~mingo/realtime-preempt/patch-2.6.22.1-rt1 I get a compile error on my x86_64 dualcore sytem. [EMAIL PROTECTED]:/usr/src/linux-2.6.22.1-rt1> make CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CHK include/linux/compile.h CC [M] net/rfkill/rfkill-input.o net/rfkill/rfkill-input.c: In function ‘rfkill_schedule_toggle’: net/rfkill/rfkill-input.c:60: error: size of array ‘type name’ is negative net/rfkill/rfkill-input.c:60: warning: comparison of distinct pointer types lacks a cast net/rfkill/rfkill-input.c:68: error: size of array ‘type name’ is negative net/rfkill/rfkill-input.c:68: warning: comparison of distinct pointer types lacks a cast net/rfkill/rfkill-input.c: At top level: net/rfkill/rfkill-input.c:82: warning: implicit declaration of function ‘__MUTEX_INITIALIZER’ net/rfkill/rfkill-input.c:82: warning: missing braces around initializer net/rfkill/rfkill-input.c:82: warning: (near initialization for ‘rfkill_wlan.mutex’) net/rfkill/rfkill-input.c:82: error: initializer element is not constant net/rfkill/rfkill-input.c:82: error: (near initialization for ‘rfkill_wlan.mutex.lock.wait_lock.raw_lock.slock’) net/rfkill/rfkill-input.c:82: error: initializer element is not constant net/rfkill/rfkill-input.c:82: error: (near initialization for ‘rfkill_wlan.lock’) net/rfkill/rfkill-input.c:83: warning: missing braces around initializer net/rfkill/rfkill-input.c:83: warning: (near initialization for ‘rfkill_bt.mutex’) net/rfkill/rfkill-input.c:83: error: initializer element is not constant net/rfkill/rfkill-input.c:83: error: (near initialization for ‘rfkill_bt.mutex.lock.wait_lock.raw_lock.slock’) net/rfkill/rfkill-input.c:83: error: initializer element is not constant net/rfkill/rfkill-input.c:83: error: (near initialization for ‘rfkill_bt.lock’) make[2]: *** [net/rfkill/rfkill-input.o] Fehler 1 make[1]: *** [net/rfkill] Fehler 2 make: *** [net] Fehler 2 I used a linux-2.6.22.tar.bz2 and applied patch-2.6.22.1.bz2 followed by patch-2.6.22.1-rt1 I had copied my .config from my (working) 2.6.22-cfs-v19 directory and issued a 'make oldconfig' using mostly defaults. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> On Friday 15 June 2007 18:59:14 Linus Torvalds wrote: > > So it's true: the GPL just gives you rights, and without it you have no > > rights (other than fair use ones etc), and blah blah. But the distinction > > between "license" vs "contract" really isn't a very important one in any > > case. > > Er, copyright law is federal, contract law is generally state level? So not > only does contract law vary a lot more by jurisdiction, but it's enforced by > different courts than suits over copyright? (You'll notice the GPL doesn't > say which state law holds sway. If it was a contract this would be kind of > important.) That seems to be a special property of the US legal system. At least I'm not aware of this or a similar distinction in e.g. germany (or most parts of europe AFAIK). Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> > > What matters is *my* intent in *choosing* the GPLv2, not *his* > > > intent in writing it. > > > > I beg to differ. By adopting _his_ license you adopted his view. [...] > > ianal, but fortunately that's not what the law is. The license says what > it says, and that is what controls. The intent of the author (of Linus > and other copyright holders) is a secondary source of information /if > and only if/ any ambiguity of meaning arises (as determined by a judge, > not by you or me). But the opinion and intent of RMS (unless adopted by > Linus) is quite immaterial. I agree with the "/if and only if/ any ambiguity of meaning arises" part. I'm sorry I didn't make that clear before. However if that situation arises (i.e. the judge decides there is an ambiguity) then as far as my experience tells me it is the intention of the author (RMS et al in this case) that counts. But I erred before... Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
o me as well then they have to extend it". Handing out a SHA1 key definitely is simple and thus IMO something I can expect them to do. I'm aware we have to disagree on this. I'm also aware that this is subject to the (IMO implied right) to run the modified code on the original HW, mostly because they can do that very easily (which would be covered by "within reason"). BTW: I can easily take the position that from a metaphysical PoV the whole concept of a copy is an illusion because every copy is in fact a modified new version (that happens to be rather similar from a certain PoV... but I disgress and don't really wish to walk that bridge :) > (a) Again, Red Hat makes DVD's that contain GPLv2'd programs on > them. Red Hat is bound by the GPL, so each work they put > on the DVD is always under the GPL, and Red Hat *must* give > you the rights that the GPL specifies. [snipped the paragraph on RH "withholding rights] Here the "within reason" kicks in. And I readily admit that you are an able intellectual acrobat who can twist arguments such that they become silly. My experience with german courts has shown me that the judges I had to deal with always and foremost did apply a reality check and did not try to bisect the consequences like an algorithm evaluated by a machine, i.e. the tried to decide what is right and wrong and not whether the letter of the contract could be twisted this or that way. > (b) Again, I make the Linux kernel available to you on a web > site, and thus distribute it to you. Do I actually give you > *all* the rights I have in it? Hell no. I cannot (and do > not even want to). As an author, I have special rights in my > code that you do not get. You get the rights spelled out in > the GPLv2, and *nothing* more. I probably haven't read all Alexandre wrote but from what I read I'd be surprised he'd disagree (I don't). > In other words, Alexandre's reading of the text in the preamble is > *impossible*. It absolutely *cannot* be the way the license works. > It's not how Red Hat itself reads it, and it's not how it can even > legally be made to work even if somebody *wanted* to read it that > way. I don't know whether Alexandre does read to preamble to mean what you imply he does. But whether he does or not is irrelevant for me to decide that IMO there is a strong argument to claim that what TiVo did is illegal even under the GPLv2. Note I'm merely saying "strong argument" as opposed to "clear beyond doubt". > > Whether or not the GPLv3 is truely an acceptable answer to prevent > > Tivoisation is a completely different issue that I can't really judge. > > Absolutely. I do think it prevents Tivoisation, but I personally think > it's unacceptable in even *trying* to prevent it, and as I've tried to > make clear, the GPLv2 definitely did *not* prevent Tivo from doing what > they did. Well, I think trying to prevent it is totally acceptable, after all I'm free to impose whatever restrictions to my code I see fit (I think it was long ago agreed that the GPLv2 does impose restrictions as well; they are just different). We have to agree to disagree on both whether trying to prevent Tivoisation is acceptable and whether GPLv2 already prevents it. Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> Because GPLv2 doesn't enforce limitations on the hardware a GPL'd work can be > put on. It doesn't make artificial distinctions between "Commercial", > "Industrial" and "User". What it does is *ATTEMPT* to ensure that nobody > receiving a copy of a GPL'd work has the same rights as any other person that > gets a copy. GPLv3 gives people *additional* rights beyond those. IMO this statement expressedly exposes the different viewpoints as used in various factions in this discussion. Without adopting all the details I think I can agree to the above stmt. However I don't agree with the implied msg as I perceive it. In the following I'll try to explain what I mean by the above. I don't know whether what TiVo did actually was allowed by the legal phrases of the GPLv2. I can image it was legally valid but I don't know. But then I'm convinced it was one of the things the inventors of the GPL wanted to make illegal by it -- they may have failed to do so when wording the legal part. I like to remind you of the story with the broken closed source printer driver RMS tried to fix at MIT (if I recall correctly) and the frustration that he couldn't do so that finally made him start the FSF. No customer can fix his TiVo box without the cooperation of the HW vendor. If they refuse there is nothing that can be done. For me this is very much like printer story above. Assuming you (the reader) agree so far: I find it obvious that the GPL was meant to prevent such to be possible. This is what I mean by the "the spirit of the GPL". Living in germany I'm also used to the courts valueing the intention over the exact wording of a contract (a licence after all is a contract). So I _think_ in germany TiVo would have lost a lawsuit if they had tried it. Now for a different PoV: Do I think Tivoisation is bad for the community ? Of course I think it is but your mileage may vary. Anyway, if one considers Tivoisation acceptable then there is no reason to stop using GPLv2. If one wishes to prevent it there are two related questions: - does GPLv2 prevent it ? - if GPLv2 does not prevent it then how can we change it to achieve that ? To me it seems as if the FSF tends to answer the first question with 'no' and consequently answers the second question with 'GPLv3'. Whether or not the GPLv3 is truely an acceptable answer to prevent Tivoisation is a completely different issue that I can't really judge. Last not least: Nothing of the above has to do with ethics, moral or any such cathegories. This is by intention. Thank you for reading thus far -- I hope I made myself clear. Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> > > able to run you modifications on the same hardware? > > > Come on! The whole idea of software is to have it run on some HW. > > > Why would I want to change it in the first place if I can't run it ? > > See the difference? Forgive my poor mastery of the english language and me letting slip this inconsistency. The first sentence you cited was a general remark IMO valid outside of this context and possibly ill placed as it was. The second sentence pertains the key msg I was trying to deliver and apparently I did a poor job in phrasing it so let me redo it: Why would I want to change the SW targetted for some HW if I can't run the changed version on said HW ? [note that for the TiVo case I possibly would not own or be able to own similar HW being able to run my modified SW; so even some HW would not be triggered either] Remember I'm discussing my understanding of the spirit of the GPL, not whether the legal part actually does give me that right enforceable in court. Here is another stmt which is valid outside of this context AFAIAC: If the GPLv2 does not legally give me the right that I think its spirit gives me then the legal phrases should be changed to achieve that. Whether or not others share my view of what the spirit of the GPL implies is completely theirs to decide and if they differ they likely won't agree on my previous stmt either. Fine with me. And this leads to another observation: IMO this thread is partly fueled by a fundamental mixing of PoVs. Some argue based on their perceived view of the spirit of the GPL and some based on the actual legal phrases in GPLv2 and GPLv3 and whether or how they reflect the perceived spirit. Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> In Germany, not America. I should have qualified my statement to make it > clear > I mean "In America". Sorry about the confusion. You shouldn't say "America" when you mean the "US". Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> > As a PS to the GPL3 comment here is the basic difference > > > > ROM - I can't modify the code on the device > > The creator can't modify the code further on the device > > > > Tivo- I can't modify the code on the device > > The owner can modify the code > > > > One is an implicit limitation of the hardware (just like I can't run > > openoffice on a 4MB PC even though the license gives me the right to > > try), the other is an artificial restriction. > > > > One case is witholding freedom in the GPL sense by one party while > > keeping it themselves, the other is a limitation of the system > > inevitably imposed on everyone. > > I've been following this discussion and I find this interesting. > Consider these two cases: > > 1.) I ship the device back to the manufacturer, they replace the ROM, > and ship it back to me. > > 2.) I ship the device back to the manufacturer, they load new code > into it, and ship it back to me. > > How do these two differ? Or is it now just a question of the ROM > being in a socket? I can't see how the technicalities of how the > hardware is constructed can change the legality of the software. At first glance I think a construct where the manufacturer is obliged to load _MY_ modified software in a timely fashion and at a reasonable price into the device would fit my understanding of the GPL's spirit though this leaves room for the definition of timely... Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> > > The fact is, Tivo didn't take those rights away from you, yet the FSF > > > says that what Tivo did was "against the spirit". That's *bullshit*. > > > > Oh, good, let's take this one. > > > > if you distribute copies of such a program, [...] > > you must give the recipients all the rights that you have > > > > So, TiVo includes a copy of Linux in its DVR. > > > > And they give you the same right that they had, which is obtain free software > that you can modify and redistribute. There's nothing in there that says they > should give you the tools they used after they received the software, which > is what you seem to be looking for. IANAL so I won't comment on the legal aspects of TiVo's doing. However it definitely is against _MY_ understanding of the spirit of the GPL. At least to me that's quite obvious. I'm sure you all know the story of the printer driver RMS couldn't fix that reportedly made him start the whole FSF business. Looking at what TiVo did I realize glaring similarities. I'm in no way related with the FSF. I hereby state I'm not parroting anyone's else position but have come to this conclusion solely on my own. > > TiVo retains the right to modify that copy of Linux as it sees fit. > > > > It doesn't give the recipients the same right. > > It does, can't you modify their kernel source? Where does it say you should > be > able to run you modifications on the same hardware? Come on! The whole idea of software is to have it run on some HW. Why would I want to change it in the first place if I can't run it ? If what they did is actually allowed by the wording of the legal phrases of the GPLv2 then that IMO is a loophole w/r to the spirit (as I understand) it and IMO should be plugged. > The only fear that I have with the whole Tivo saga, is that companies like > Dell can use the same thing to say: "Our hardware will only run Company's X > distribution of Linux". Would not such a restriction voilate the spirit of the GPL ? Anyway, my simplistic view is: Once it is under the GPL I could change it and actually make the changes work as I see fit. That's what I think my freedom as of the GPL is about. Now all that needs to be done is make sure the legal phrases are such that they convince the judges they actually mean this in court too. Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> Please read the German "Gesetz über Urheberrecht und verwandte > Schutzrechte" before making completely false claims - in Germany it's > 70 years after the death of the author. Oups, I had been mixing up named published works and anonymously published works. My previous claim is valid for anonymously published work only and thus holds no relevance for the situation discussed. I apologize for having raised a false claim. The copyright for works with a known is valid for 70 years after the authors death. Sorry, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[legal precedence to force waiving copyright> > A legal precedent valid in all jurisdictions? > > Harald suceessfully takes legal actions against people violating his > copyright on the Linux kernel under the terms of the GPL in Germany at > German courts based on German laws. > > If someone finds any legal precedent in Finland or the USA or Russia > that some copyright would have lapsed for some reason, would this have > any legal effect in Germany? That is difficult but AFAIK it work in the "increase protection" direction but not the other way around, at least in germany. For example even though the copyright on Micky Mouse is no longer valid by german law it is still enforcible under german law because the german jurisdiction does acknowledge the (recently extended) longer such period in the US. Apart from that I'm sure you'd find some state "legally" waiving a copyright on whatever. If that would start an avalanche of similar terminations everywhere else I'd be utterly surprised. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
> In most of the law systems out there the copyright stays valid for 70 > years (or so) after the holder's death. [I don't want to appear picky but IMO it is important to be as precise as one could possibly be, therefor...] That is not quite correct. At least for the german law system and presumably for most if not all similar systems the corrrect stmts is: In most of the law systems out there the copyright stays valid for 70 years (or so) after initial publication of the copyrighted work. For work whose publication date can't be determined (*) (e.g. unpublished work) the creators death is assumed to be the publication date for the sake of determining the aforementioned 70 years protection period. (*) "can't be determined" does not apply for published work with an insecure initial publication date. In those cases the earliest documented publication (i.e. prooveable in court) is considered the initial publication .date Note that the original phrase could last indefinitely by simply moving the copyright from person to person. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
> That's because the whole premise of your benchmark relies on a workload that > yield()s itself to the eyeballs on most graphic card combinations when using > glxgears. Your test remains a test of sched_yield in the presence of your > workloads rather than anything else. If people like ck2 it's because in the > real world with real workloads it is better, rather than on a yield() based > benchmark. Repeatedly the reports are that 3d apps and games in normal usage > under -ck are better than mainline and cfs. While I can't comment on the technical/implementational details of Con's claim I definitely have to agree from a users POV. All my recent CPU intensive benchmarks show that both ck/sd and cfs are very decent scheduler and IMO superior to mainline for all _my_ usecases. In particular playing supertux while otherwise fully utilizing both CPUs on a dualcore works without any glitch and better than on mainline for both sd and cfs. For me the huge difference you have for sd to the others increases the likelyhood the glxgears benchmark does not measure scheduling of graphic but something else. Anyway, I'm still in the process of collecting data or more precisely until recently constantly refined what data to collect and how. I plan to provide new benchmark results on CPU intensive tasks in a couple of days. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part.
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
> > I don't want to say the values aren't useful. I simply think there is > > a high noiselevel. > > The noise is reflected in the standard deviation he has on those rows. > The average +- stdev of one overlaps the average +- stdev of the > other, For the fairness test on cfs13 this simply is wrong. And for the test to be stable would require that avg of one is within avg+-stddev of the other (simple overlap does not suffice). Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpOZ4X7SfweE.pgp Description: PGP signature
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
> Okay, here's a bonus, http://www.tmr.com/~davidsen/sched_smooth_02.html > not only has the right values, the labels are changed, and I included > more data points from the fc6 recent kernel and the 2.6.21.1 kernel with > the mainline scheduler. > > The nice thing about this test and the IPC test I posted recently is > that they are reasonable stable on the same hardware, so even if someone > argues about what they show, they show the same thing each time and can > therefore be used to compare changes. I'm not sure I follow you here. The difference between 2.6.21 and 2.6.21.1 are two simple (as in involving little code) changes to ip4 and ip6 net and I'm not even sure that code is used at all in your tests. [Read: IMO the 2.6.21 and 2.6.21.1 figures are for identical cases]. Assuming the above is correct then IMO the variance between the two "dublicated" lines (cfs-v13 and sd048) is such that I would not have written "that they are reasonable stable on the same hardware". I don't want to say the values aren't useful. I simply think there is a high noiselevel. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgp2m90wGTKCm.pgp Description: PGP signature
Re: Linux 2.6.22-rc1
> >Seriously, it might be a tad more efficient if the help texts were > >written by those who invented the options in the first place. > > menuconfig NETDEV_1 > bool "Ethernet (10GbE)" > ---help-- > Say Y here to actually be able to go into this menu > and select some drivers that we think belong to the > "10 Gigabit Ethernet" family. > > If unsure, it is unwise to say N! > > See, this looks so fundamentally basic to me that I find it > almost funny. YMMV, hence I asked for suggestions from > other people. I remember very well the time when I first issued make menuconfig. Ever since then I've been grateful for all those "fundamentally basic" explanations. And I've learned quite alot about kernelconfig just by reading them. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpR0U6biGdbj.pgp Description: PGP signature
[REPORT] cfs-v9 vs sd048 vs mainline
Hi list, here is another round of numbercrunching tests done with the following schedulers/kernels: 2.6.21.1 (mainline) 2.6.21-sd046 2.6.21.1-sd048 2.6.21-cfs-v6 2.6.21.1-cfs-v7 2.6.21.1-cfs-v9 running on a dualcore x86_64. The tests consist of 3 tasks (named LTMM, LTMB and LTBM). The only I/O they do is during init and for logging the results, the rest is just floating point math. There are 3 scenarios: j1 - all 3 tasks run sequentially /proc/sys/kernel/sched_granularity_ns=400 /proc/sys/kernel/rr_interval=16 j3 - all 3 tasks run in parallel /proc/sys/kernel/sched_granularity_ns=400 /proc/sys/kernel/rr_interval=16 j3big - all 3 tasks run in parallel with timeslice extended by 2 magnitudes (not run for mainline) /proc/sys/kernel/sched_granularity_ns=4 /proc/sys/kernel/rr_interval=400 All 3 tasks are run while the system does nothing else except for the "normal" (KDE) daemons. The system had not been used for interactive work during the tests. I'm giving user time as provided by the "time" cmd followed by wallclock time (all values in seconds). LTMM j1 j3 j3big 2.6.21.1-cfs-v9 8334.37/ 8388 5472.40/ 7459 5422.36/ 7832 (repetition) 8288.56/ 8341 5485.95/ 5647 2.6.21.1-cfs-v7 5690.27/ 5715 5396.31/ 9719 5424.92/ 8956 (repetition) 5860.11/ 8993 2.6.21-cfs-v65655.07/ 5682 5437.84/ 5531 5434.04/ 8072 (repetition) 5677.39/ 5704 5509.13/ 8882 (repetition) 5711.32/ 5732 2.6.21-sd-0485309.64/ 5320 5517.64/ 8630 5416.81/ 8258 2.6.21-sd-0465556.44/ 5583 5446.86/ 8037 5407.50/ 8274 2.6.21.1 5417.62/ 5439 5422.37/ 7132 na /na LTMB j1 j3 j3big 2.6.21.1-cfs-v9 11647.24/11717 7519.84/ 9494 7477.55/10191 (repetition) 11393.62/11460 7557.37/10403 2.6.21.1-cfs-v7 7838.12/ 7869 7559.00/10922 7480.03/10955 (repetition) 7612.38/ 9874 2.6.21-cfs-v67729.81/ 7755 7470.10/10244 7449.16/10186 (repetition) 7597.83/10297 2.6.21-sd-0487311.68/ 7323 7564.44/10591 7665.00/10435 2.6.21-sd-0467611.00/ 7626 7573.16/10109 7458.10/10316 2.6.21.1 7438.31/ 7461 7620.72/11087 na /na LTBM j1 j3 j3big 2.6.21.1-cfs-v9 10984.06/11058 8700.88/12373 7496.45/10300 (repetition) 11961.47/12030 7550.49/10382 2.6.21.1-cfs-v7 7899.38/ 7939 7558.41/ 9576 7514.79/ 9615 (repetition) 7833.86/11553 2.6.21-cfs-v67720.70/ 7746 7567.09/10362 7464.17/10335 (repetition) 7601.55/10578 2.6.21-sd-0487344.96/ 7357 7589.05/10235 7547.09/10379 2.6.21-sd-0467431.06/ 7452 7539.83/10600 7474.20/10222 2.6.21.1 7452.80/ 7481 7484.19/ 9570 na /na LTMM+LTMB+LTBM j1 j3 j3big 2.6.21.1-cfs-v9 30965.67/31163 21693.12/29326 20396.36/28323 2.6.21.1-cfs-v7 21427.77/21523 20513.72/30217 20419.74/29526 2.6.21-cfs-v6 21105.58/21183 20475.03/26137 20347.37/28593 2.6.21-sd-048 19966.28/2 20671.13/29456 20628.90/29072 2.6.21-sd-046 20598.50/20661 20559.85/28746 20339.80/28812 2.6.21.120308.73/20381 20527.28/27789 na /na User time apparently is subject to some variance. I'm particularly surprised by the wallclock time of scenario j1 and j3 for case LTMM with 2.6.21-cfs-v6 and in particular 2.6.21.1-cfs-v9. I'm not sure what to make of this. Repetitions of this test show these results to be stable. Also surpising is the wallclock time difference between j1 and j3 for LTMM with 2.6.21.1-cfs-v7. Repeating the test does give roughly the same result though. The reproduceable differences between j1 and j3 on 2.6.21.1-cfs-v9 IMO suggests there is something very strange happening. It should not be possible for j1 to be faster than j3 because scenario j1 should constitute the "true" time each task requires. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpOSsq7YDnBq.pgp Description: PGP signature
Re: [REPORT] 2.6.21.1 vs 2.6.21-sd046 vs 2.6.21-cfs-v6
> regarding the fairness of the different schedulers, please note the > different runtimes for each component of the workload: > > LTMM: 5655.07/ 5682 > LTMB: 7729.81/ 7755 > LTBM: 7720.70/ 7746 > > this means that a fair scheduler would _not_ be the one that finishes > them first on wall-clock time (!). A fair scheduler would run each of > them at 33% capacity until the fastest one (LTMM) reaches ~5650 seconds > runtime and finishes, and _then_ the remaining ~2050 seconds of runtime > would be done at 50%/50% capacity between the remaining two jobs. I.e. > the fair wall-clock results should be around: > > LTMM: ~8500 seconds > LTMB: ~10600 seconds > LTBM: ~10600 seconds > > (but the IO portion of the workloads and other scheduling effects could > easily shift these numbers by a few minutes.) Correct. I will try to cook up some statistics for the next round of results (been redoing cfs-v6, done cfs-v7 and then redone it because of strange results and hopefully will do cfs-v8 tonight as well as sd048 during the next days -- not easy to keep up with you guys rolling out new versions ;-) > regarding the results: it seems the wallclock portion of LTMM/j3 is too > small - even though the 3 tasks ran in parallel, in the CFS test LTMM > finished just as fast as if it were running alone, right? Right. I'm really very surprised but this remained while redoing both LTMM/j1 (twice!) and LTMM/j3 with cfs-v6. I don't really understand that and now think it shows some hidden "fairness deficiency" that hopefully is corrected in cfs-v8. At least cfs-v7 did behave differently. > That does not > seem to be logical and indeed suggests some sort of testing artifact. Since it doesn't appear with any other scheduler tested I'd not rule out a feature of the code. > That makes it hard to judge which scheduler achieved the above 'ideal > fair distribution' of the workloads better - for some of the results it > was SD, for some it was CFS - but the missing LTMM/j3 number makes it > hard to decide it conclusively. They are certainly both close enough and > the noise of the results seems quite high. Oh, I'm confident both are excellent scheduler. On the other hand I find mainline isn't that bad either, at least for this type of load. Anyway, as I wrote above I'm continuing my tests and am collecting data for the various scheduler. Presumably over the weekend I'll mail out the next round. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpkCvzuyOIBw.pgp Description: PGP signature
Re: VMware, x86_64 and 2.6.21.
> Does anyone have VMware working on x86_64 with 2.6.21? VMware server 1.0.2 (free edition) is working fine here with 2.6.21.1 using vmware-any-any-update109. System is Intel Core2 T7600 (x86_64) Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpMLxjE1XYXU.pgp Description: PGP signature
[REPORT] 2.6.21.1 vs 2.6.21-sd046 vs 2.6.21-cfs-v6
i list, meanwhile I've redone my numbercrunching tests with the following kernels: 2.6.21.1 (mainline) 2.6.21-sd046 2.6.21-cfs-v6 running on a dualcore x86_64. [I will run the same test with 2.6.21.1-cfs-v7 over the next days, likely tonight] The tests consist of 3 tasks (named LTMM, LTMB and LTBM). The only I/O they do is during init and for logging the results, the rest is just floating point math. There are 3 scenarios: j1 - all 3 tasks run sequentially /proc/sys/kernel/sched_granularity_ns=400 /proc/sys/kernel/rr_interval=16 j3 - all 3 tasks run in parallel /proc/sys/kernel/sched_granularity_ns=400 /proc/sys/kernel/rr_interval=16 j3big - all 3 tasks run in parallel with timeslice extended by 2 magnitudes (not run for mainline) /proc/sys/kernel/sched_granularity_ns=4 /proc/sys/kernel/rr_interval=400 All 3 tasks are run while the system does nothing else except for the "normal" (KDE) daemons. The system had not been used for interactive work during the tests. I'm giving user time as provided by the "time" cmd followed by wallclock time (all values in seconds). LTMM j1 j3 j3big 2.6.21-cfs-v65655.07/ 5682 5437.84/ 5531 5434.04/ 8072 2.6.21-sd-0465556.44/ 5583 5446.86/ 8037 5407.50/ 8274 2.6.21.1 5417.62/ 5439 5422.37/ 7132 na /na LTMB j1 j3 j3big 2.6.21-cfs-v67729.81/ 7755 7470.10/10244 7449.16/10186 2.6.21-sd-0467611.00/ 7626 7573.16/10109 7458.10/10316 2.6.21.1 7438.31/ 7461 7620.72/11087 na /na LTBM j1 j3 j3big 2.6.21-cfs-v67720.70/ 7746 7567.09/10362 7464.17/10335 2.6.21-sd-0467431.06/ 7452 7539.83/10600 7474.20/10222 2.6.21.1 7452.80/ 7481 7484.19/ 9570 na /na LTMM+LTMB+LTBM j1 j3 j3big 2.6.21-cfs-v6 21105.58/21183 20475.03/26137 20347.37/28593 2.6.21-sd-046 20598.50/20661 20559.85/28746 20339.80/28812 2.6.21.120308.73/20381 20527.28/27789 na /na User time apparently is subject to some variance. I'm particularly surprised by the wallclock time of scenario j1 and j3 for case LTMM with 2.6.21-cfs-v6. I'm not sure what to make of this, i.e. whether I had happening something else on my machine during j1 of LTMM -- that's always been the first test I ran and it might be that there were still some other jobs running after the initial boot. Assuming scenario j1 does constitute the "true" time each task requires and also assuming each scheduler makes maximum use of the available CPUs (the tests involve very little I/O) one could compute the expected wallclock time. However since I suspect the j1 figures of LTMM to be somewhat "dirty" I'll refrain from it. However from these figures it seems as if sd does provide for the fairest (as in equal share for all) scheduling among the 3 schedulers tested. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpDL74oImtfK.pgp Description: PGP signature
Re: [ck] Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7
> Very interesting indeed but fairly complicated as well. Sorry for that -- I've taken these figures from the 3MB logfile that each job creates and "reading" them on a regular basis tend to forget that probably everyody else does not find them as obvious as I do. Also I'm don't really have lots of experience with how a scheduler is properly tested. For any upcoming tests I will restrict the numbers to wallclock and what time provides which probably is better suited anyway. > > as a summary: i think your numbers demonstrate it nicely that the > > shorter 'timeslice length' that both CFS and SD utilizes does not have a > > measurable negative impact on your workload. To measure the total impact > > of 'timeslicing' you might want to try the exact same workload with a > > much higher 'timeslice length' of say 400 msecs, via: > > > > echo 4 > /proc/sys/kernel/sched_granularity_ns # on CFS > > echo 400 > /proc/sys/kernel/rr_interval # on SD > > I thought that the effective "timeslice" on CFS was double the > sched_granularity_ns so wouldn't this make the effective timeslice double > that of what you're setting SD to? Anyway the difference between 400 and > 800ms timeslices is unlikely to be significant so I don't mind. I'm happy to do that, hopefully over the weekend. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpgEbzHujiUn.pgp Description: PGP signature
Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7
you'd naturally want to overlap these workloads to utilize the CPUs, so > the numbers you did are very relevant too.) Yes. In fact the workloads used to be run serialized and only recently I tried to easily have them run on multicore systems. The whole set of such jobs consists of 312 tasks and thus the idea is to get a couple of PS3 and have them run there... (once I found the time to port the software). > The vmstat suggested there is occasional idle time in the system - is > the workload IO-bound (or memory bound) in those cases? There is writing out stats after each run (i.e. every 5-8 sec) both to the PostgreSQL DB as well as to the console. I could get rid of the console I/O (i.e. make it conditional) and for testing purpose could switch off the DB if that would make be helpful. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpthfSDi0N4F.pgp Description: PGP signature
[REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7
eDB # 1711 Su0.29 ~ 0.0002 real133m50.274s user91m2.485s sys 0m10.801s Job LTMB End: 23:01:54.763 GC2 20070101 LTMB Wed Apr 25 23:01:35.274 2007: 169.88 Min., 5.9573 sec/run (1711 runs) Ranking-3.pl finished after 7452.300s(CPU) and 10208 Sek. times: bewerteUmgeb #1 Su0.76 ~ 0.7600 times: evalMarkt # 1711 Su 7438.33 ~ 4.3474 times:writeDB # 1711 Su0.25 ~ 0.0001 real170m12.885s user124m12.562s sys 0m14.705s Job LTBM End: 23:09:16.506 GC2 20070101 LTBM Wed Apr 25 23:08:59.376 2007: 177.28 Min., 6.2168 sec/run (1711 runs) Ranking-3.pl finished after 7673.940s(CPU) and 10652 Sek. times: bewerteUmgeb #1 Su0.78 ~ 0.7800 times: evalMarkt # 1711 Su 7659.10 ~ 4.4764 times:writeDB # 1711 Su0.30 ~ 0.0002 real177m35.890s user127m54.376s sys 0m9.873s From fairly early during the job: top - 20:15:13 up 12 min, 9 users, load average: 3.89, 2.61, 1.52 Tasks: 3 total, 3 running, 0 sleeping, 0 stopped, 0 zombie Cpu(s): 99.8%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 3348628k total, 1109020k used, 2239608k free,28820k buffers Swap: 2097144k total,0k used, 2097144k free, 511352k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 6389 mgd 25 0 92776 17m 3668 R 100 0.5 2:50.23 perl 6390 mgd 25 0 93932 18m 3668 R 53 0.6 2:08.47 perl 6393 mgd 25 0 93880 18m 3668 R 47 0.6 1:42.53 perl procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 6 0 0 2211984 30780 52561200 0 0 490 1318 100 0 0 0 4 0 0 2211460 30872 52557600 8 795 489 1052 100 0 0 0 3 0 0 2211736 30896 52562000 0 129 467 1003 99 1 0 0 7 0 0 2211024 30896 52562400 097 469 1234 100 0 0 0 4 0 0 2211080 30924 52562400 0 147 472 1117 100 0 0 0 4 0 0 2211008 30936 52561600 035 467 1086 100 0 0 0 5 0 0 2210792 30976 52563200 0 144 480 1120 100 0 0 0 5 0 0 2210932 30992 52562000 047 462 1099 99 1 0 0 3 0 0 2210948 31000 52564400 040 460 1087 100 0 0 0 4 0 0 2210980 31016 52564800 041 453 898 100 0 0 0 4 0 0 2210716 31036 52564800 199 471 1322 100 0 0 0 4 0 0 2210748 31052 52564800 060 454 1085 100 0 0 0 5 0 0 2210764 31080 52565200 068 463 1007 100 0 0 0 5 0 0 2210796 31080 52565600 068 462 962 100 0 0 0 5 0 0 2210812 31104 52566400 097 470 1193 100 0 0 0 5 0 0 2210812 31104 52566400 0 0 451 911 100 0 0 0 4 0 0 2210812 31128 52567200 069 465 1100 100 0 0 0 3 0 0 2210300 31152 52566000 0 143 466 1350 99 1 0 0 4 0 0 2210292 31152 52567600 3 9 513 2025 100 0 0 0 6 0 0 2210624 31196 52570000 3 133 492 1207 100 0 0 0 4 0 0 2210460 31196 52572000 0 0 458 1086 100 0 0 0 Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgp2WtbZcjo0N.pgp Description: PGP signature
Re: [ck] [REPORT] cfs-v5 vs sd-0.46
> > with cfs-v5 finally booting on my machine I have run my daily > > numbercrunching jobs on both cfs-v5 and sd-0.46, 2.6.21-v7 on > > top of a stock openSUSE 10.2 (X86_64). > > Thanks for testing. I actually enjoyed it -- the more extensive test I had promised two days ago is almost finished. There is just one test I have yet to (re)run and I will have a slot for it later today so I'll mail out the results comparing 2.6.21-rc7 (mainline) 2.6.21-rc7-sd046 2.6.21-rc7-cfs-v6-rc2 (X @ nice 0) 2.6.21-rc7-cfs-v6-rc2 (X @ nice -10) during the early afternoon (my time). > You have 3 tasks and only 2 cpus. The %cpu is the percentage of the cpu the > task is currently on that it is using; it is not the percentage of > the "overall cpu available on the machine". Since you have 3 tasks and 2 > cpus, the extra task will always be on one or the other cpu taking half of > the cpu but never on both cpus. I had assumed that given the interval of 3 sec the three tasks would be evenly distributed among the 2 CPUs thus resulting in a CPU% of 66 each because that's what they get in the long run anyway. Apparently 3 sec is too short an interval to see this. > What is important is that if all three tasks are fully cpu bound and started > at the same time at the same nice level, that they all receive close to the > same total cpu time overall showing some fairness is working as well. This > should be the case no matter how many cpus you have. They are started via 'make -j3' which implies they start at the same time (i.e. within a few msec). They initially load some data and then perform extensive computations on that data. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgplQ8ciID60h.pgp Description: PGP signature
Re: [REPORT] cfs-v5 vs sd-0.46
> oh, you are writing the number-cruncher? Yep. > In general the 'best' > performance metrics for scheduler validation are the ones where you have > immediate feedback: i.e. some ops/sec (or ops per minute) value in some > readily accessible place, or some "milliseconds-per-100,000 ops" type of > metric - whichever lends itself better to the workload at hand. I'll have to see whether that works out. I don't have an easily available ops/sec but I guess I could create something similar. > If you > measure time then the best is to use long long and nanoseconds and the > monotonic clocksource: [snip] Thanks, I will implement that, for Linux anyway. > Plus an absolute metric of "the whole workload took X.Y seconds" is > useful too. That's the easiest to come by and is already available. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpwqhqmZDVz7.pgp Description: PGP signature
Re: [REPORT] cfs-v5 vs sd-0.46
> Here i'm assuming that the vmstats are directly comparable: that your > number-crunchers behave the same during the full runtime - is that > correct? Yes, basically it does (disregarding small fluctuations) I'll see whether I can produce some type of absolute performance measure as well. Thinking about it I guess this should be fairly simple to implement. Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgprODjr3hqXe.pgp Description: PGP signature
Re: [REPORT] cfs-v5 vs sd-0.46
> > What I also don't understand is the difference in load average, sd > > constantly had higher values, the above figures are representative for > > the whole log. I don't know which is better though. > > hm, it's hard from here to tell that. What load average does the vanilla > kernel report? I'd take that as a reference. I will redo this test with sd-0.46, cfs-v5 and mainline later today. > interesting - CFS has half the context-switch rate of SD. That is > probably because on your workload CFS defaults to longer 'timeslices' > than SD. You can influence the 'timeslice length' under SD via > /proc/sys/kernel/rr_interval (milliseconds units) and under CFS via > /proc/sys/kernel/sched_granularity_ns. On CFS the value is not > necessarily the timeslice length you will observe - for example in your > workload above the granularity is set to 5 msec, but your rescheduling > rate is 13 msecs. SD default to a rr_interval value of 8 msecs, which in > your workload produces a timeslice length of 6-7 msecs. > > so to be totally 'fair' and get the same rescheduling 'granularity' you > should probably lower CFS's sched_granularity_ns to 2 msecs. I'll change default nice in cfs to -10. I'm also happy to adjust /proc/sys/kernel/sched_granularity_ns to 2msec. However checking /proc/sys/kernel/rr_interval reveals it is 16 (msec) on my system. Anyway, I'll have to do some urgent other work and won't be able to do lots of testing until tonight (but then I will). Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpfJX2s3TRBz.pgp Description: PGP signature
[REPORT] cfs-v5 vs sd-0.46
60 82802000 0 189 470 1538 99 1 0 0 3 0 0 1701476 63968 82802000 057 461 100 0 0 0 4 0 0 1701508 63996 82804400 0 105 458 1093 99 1 0 0 4 0 0 1701428 64012 82804400 0 127 471 1341 100 0 0 0 5 0 0 1701356 64028 82804000 055 458 1344 100 0 0 0 3 0 0 1701356 64028 82805600 015 462 1291 100 0 0 0 cfs-v5 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 6 0 0 2157728 31816 54523600 0 103 543 748 100 0 0 0 4 0 0 2157780 31828 54525600 063 435 752 100 0 0 0 4 0 0 2157928 31852 54525600 0 105 424 770 100 0 0 0 4 0 0 2157928 31868 54526800 0 261 457 763 100 0 0 0 4 0 0 2157928 31884 54528000 0 113 435 765 100 0 0 0 4 0 0 2157928 31900 54528800 052 422 745 100 0 0 0 4 0 0 2157556 31932 54528400 0 169 436 1010 100 0 0 0 4 0 0 2157556 31952 54529600 072 424 736 100 0 0 0 4 0 0 2157556 31960 54530400 035 428 743 100 0 0 0 4 0 0 2157556 31984 54530800 091 425 710 99 1 0 0 4 0 0 2157556 31992 54532000 035 428 738 100 0 0 0 5 0 0 2157556 32016 54532000 0 105 425 729 100 0 0 0 4 0 0 2157432 32052 54533600 0 197 434 989 99 1 0 0 5 0 0 2157448 32060 54535200 036 421 767 100 0 0 0 4 0 0 2157448 32076 54535600 0 127 441 752 100 0 0 0 6 0 0 2157448 32092 54536800 069 422 784 99 1 0 0 4 0 0 2157324 32116 54538800 0 191 445 734 100 0 0 0 4 0 0 2157200 32148 54540000 0 123 427 773 100 0 0 0 4 0 0 2157200 32156 54541200 039 428 713 100 0 0 0 7 0 0 2156844 32184 54541200 1 161 429 1360 99 1 0 0 6 0 0 2156348 32192 54541600 032 427 723 100 0 0 0 Last not least I'd like to add that at least on my system having X niced to -19 does result in kind of "erratic" (for lack of a better word) desktop behavior. I'll will reevaluate this with -v6 but for now IMO nicing X to -19 is a regression at least on my machine despite the claim that cfs doesn't suffer from it. Best, Michael PS: Only learning how to test these things I'm happy to get pointed out the shortcomings of what I tested above. Of course suggestions for improvements are welcome. -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpDmP3D8nEwX.pgp Description: PGP signature
Re: [ck] Re: [ANNOUNCE] Staircase Deadline cpu scheduler version 0.45
> Anyway the more important part is... Can you test this patch please? Dump > all the other patches I sent you post 045. Michael, if you could test too > please? Have it up running for 40 minutes now and my perljobs show a constant cpu utilization of 100/50/50 in top most of the time. When the 100% job goes down to e.g. 70% these 30% are immediately reclaimed by the other two, i.e. the total sum of all three stays with 2% point of 200%. From here it seems as if your latest patch did what is was supposed to :-) Best, Michael PS: While these numbercrunching jobs were running I started another kde session and have my children play supertux for 20 minutes. While the system occasionally was not as responsive as it is when there is little load, supertux remained very playable. -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpqVf9ejWzeo.pgp Description: PGP signature
Re: [patch] CFS scheduler, v4
> i'm pleased to announce release -v4 of the CFS patchset. The patch > against v2.6.21-rc7 can be downloaded from: > > http://redhat.com/~mingo/cfs-scheduler/ I can't get 2.6.21-rc7-CFS-v4 to boot. Immediately after selecting this kernel I see a very fast scrolling (loop?) sequence of addrs which I don't know how to stop to write them down. They don't appear in any kernel log either. However I see two Tux at the top of the screen. I'm using the very same .config I also use with 2.6.21-rc7-sd0.x What could be wrong and how could I track that down ? FWIW this also happened with 2.6.21-rc7-CFS-v3 and thus for 2.6.21-rc7-CFS-v4 I did a pristine extract of 2.6.20.tar.bz2 and applied all patches freshly. System is a Dell XPS M1710, Intel Core2 T7600 2.33, 4GB Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpp4LQ8jBmat.pgp Description: PGP signature
Re: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.45
Hi Con, I now have 2.6.21-rc7-sd-0.45 running on my Intel Core2 T7600 2.33 machine and there is something I don't understand. For testing I have a Perl script that does some numbercrunching and runs a couple of hours. I have two scenarios a) start the job via loops in a shellscript b) start the job via a makefile (make -j 2) that I run in parallel. I watch the jobs via top and this is what I see: Job a) quickly gets about 100% (- 0-2) while job b) creates two perl jobs that both get 50% (- 0-2). I suppose it is expected behaviour that the single perl job created via a) gets same same share of the cpu as the two perl jobs created via b) together. However occasionally cpu drops to 33% for all three perl jobs while there is no other job visible in top (i.e. the sum drops from 200% to 100%). After some time this changes back to 100/50/50. How could this happen and would applying the other patch you mailed to Willy Tarreau help tracking that down ? Best wishes, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpa9Kijctju0.pgp Description: PGP signature
Re: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.43
> In order to keep raising the standard for comparison for the alternative new > scheduler developments, here is an updated version of the staircase deadline > cpu scheduler. I very much appreciate your continued work on SD. Over the last days I had used 26.21-rc7-ck1 and -ck2. Today I have given sd0.42 a try and my system "feels" more responsive with my everyday tasks. No hard facts just my very subjective usage experience. I'm on an Intel Core2 T7600 2.33GHz, 4GB, openSUSE 10.2, KDE Workload are occasional compilejobs as well as regular Perl numbercrunching scripts while having amarok playing music. No noticeable desktop freezes or anything else. With -ck1/2 I had occasional visual freezes/delays. I think I still like SD better than the "old" -ck. I'll give 2.6.21-rc7-sd0.43 a try later today (i.e. when it has finished been built). Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgphOON3ivWcy.pgp Description: PGP signature
