Re: IBM PPC 405 series little endian?
On Mon, 11 Jun 2001, Troy Benjegerdes wrote: > On Mon, Jun 11, 2001 at 01:34:21PM +0200, Zehetbauer Thomas wrote: > > Has someone experimented with running linux in little-endian mode on IBM > > PowerPC 405 (Walnut) yet? > > With the possible exception of the matrox guy, I haven't heard of ANYONE > running in LE mode on ppc. The second problem is going to be to recompile > ALL the applications you want and hope they work. actually, we run ppc 603, 750 and 74xx series ppc's little endian in a PCI based shared memory multicomputer. we also run them big-endian in the VME based version. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IBM PPC 405 series little endian?
On Mon, 11 Jun 2001, Troy Benjegerdes wrote: On Mon, Jun 11, 2001 at 01:34:21PM +0200, Zehetbauer Thomas wrote: Has someone experimented with running linux in little-endian mode on IBM PowerPC 405 (Walnut) yet? With the possible exception of the matrox guy, I haven't heard of ANYONE running in LE mode on ppc. The second problem is going to be to recompile ALL the applications you want and hope they work. actually, we run ppc 603, 750 and 74xx series ppc's little endian in a PCI based shared memory multicomputer. we also run them big-endian in the VME based version. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 06 Jun 2001, Dr S.M. Huen wrote: > The whole screaming match is about whether a drastic degradation on using > swap with less than the 2*RAM swap specified by the developers should lead > one to conclude that a kernel is "broken". I would argue that any system that performs substantially worse with swap==1xRAM than a system with swap==0xRAM is fundamentally broken. it seems that w/ todays 2.4.x kernel, people running programs totalling LESS THAN their physical dram are having swap problems. they should not even be using 1 byte of swap. the whole point of swapping pages is to give you more memory to execute programs. if I want to execute 140MB of programs+kernel on a system with 128 MB of ram, I should be able to do the job effectively with ANY amount of "total memory" exceeding 140MB. not some hokey 128MB RAM + 256MB swap just because the kernel it too fscked up to deal with a small swap file. -- /*--------** ** Mark Salisbury | Mercury Computer Systems** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 06 Jun 2001, Dr S.M. Huen wrote: The whole screaming match is about whether a drastic degradation on using swap with less than the 2*RAM swap specified by the developers should lead one to conclude that a kernel is broken. I would argue that any system that performs substantially worse with swap==1xRAM than a system with swap==0xRAM is fundamentally broken. it seems that w/ todays 2.4.x kernel, people running programs totalling LESS THAN their physical dram are having swap problems. they should not even be using 1 byte of swap. the whole point of swapping pages is to give you more memory to execute programs. if I want to execute 140MB of programs+kernel on a system with 128 MB of ram, I should be able to do the job effectively with ANY amount of total memory exceeding 140MB. not some hokey 128MB RAM + 256MB swap just because the kernel it too fscked up to deal with a small swap file. -- /*** ** Mark Salisbury | Mercury Computer Systems** ***/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
On Mon, 23 Apr 2001, Ulrich Windl wrote: > IMHO the POSIX is doable to comply with POSIX. Probably not what many > of the RT freaks expect, but doable. I'm tuning the nanoseconds for a > while now... > > Ulrich thanks for calling me a freak :) yes, linux could have posix timers cobbled on today and comply with the POSIX spec. but, we would like to make it better, not just feature complete. 10ms timer resolutions, while completely in compliance w/ the posix spec, are completely useless for "RT freaks" remember that 95% of all computers in the world are embedded and of those most nead at least "soft" RT behavior. seems like a good growth market for linux to me. when a PPC G4 is capable of 30 nanosecond resolution, why would you want to settle for 10 millisecond (30 billionths of a second vs 10 thousandths for those of you who haven't had to familiarize yourselves with sub-second time units) > > On 17 Apr 2001, at 11:53, george anzinger wrote: > > > I was thinking that it might be good to remove the POSIX API for the > > kernel and allow a somewhat simplified interface. For example, the user > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[WAAAY OT]Re: ANNOUNCE New Open Source X server
On Wed, 18 Apr 2001, Scott Prader wrote: > the 'latest RAD toolkits' now THERE'S something decent worth quoting, I > hope you won't mind me doing so. :) So, going back to the above, and > again, let me know if i'm wrong here, you're saying that in order to > support a decent X server project, there NEEDS to be 'RAD toolkits', > they can't be mediocre, less memory hungry, etc.. they have to be "RAD", > which is quite a vague term. Perhaps you could elaborate on this, > perferably in private email seeing as how the scope of this topic is > really not fit for this mailing list. funny, I could swear that RAD was an acronym for Rapid Application Development as opposed to your farcical interpretation. you complain about other people being hateful, but as I read it you threw the first fireball. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[WAAAY OT]Re: ANNOUNCE New Open Source X server
On Wed, 18 Apr 2001, Scott Prader wrote: the 'latest RAD toolkits' now THERE'S something decent worth quoting, I hope you won't mind me doing so. :) So, going back to the above, and again, let me know if i'm wrong here, you're saying that in order to support a decent X server project, there NEEDS to be 'RAD toolkits', they can't be mediocre, less memory hungry, etc.. they have to be "RAD", which is quite a vague term. Perhaps you could elaborate on this, perferably in private email seeing as how the scope of this topic is really not fit for this mailing list. funny, I could swear that RAD was an acronym for Rapid Application Development as opposed to your farcical interpretation. you complain about other people being hateful, but as I read it you threw the first fireball. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
ot be adjusted. This means that > relative timers and absolute timers related to CLOCK_UPTIME are not > affected by the above wall time adjustments.) absolute timers will automatically fall out when you adjust CLOCK_UPTIME... i.e. an absolute time is an absolute time and since CLOCK_UPTIME is the ultimate arbiter of what absolute time it is, adjusting CLOCK_UPTIME will cause the absolute times in the timer list to be handled properly without modifying them. (am I makeing myself clear? I will try to come up with a better description of what I mean) > In either a ticked or tick less system, it is expected that resolutions > higher than 1/HZ will come with some additional overhead. For this > reason, the CLOCK resolution will be used to round up times for each > timer. When the CLOCK provides 1/HZ (or coarser) resolution, the > project will attempt to meet or exceed the current systems timer > performance. ONLY in a ticked system. > > Safe guards: > > Given a system speed, there is a repeating timer rate which will consume > 100% of the system in handling the timer interrupts. An attempt will > be made to detect this rate and adjust the timer to prevent system > lockup. This adjustment will look like timer overruns to the user > (i.e. we will take a percent of the interrupts and record the untaken > interrupts as overruns). see my earlier e-mail, although it is a simple matter to enforce a minimum allowable interval by parameter checking. > > What the project will NOT do: > > This project will NOT provide higher resolution accounting (i.e. user > and system execution times). > > The project will NOT provide higher resolution VIRTUAL or PROFILE timers. as I said, there are some kool things we could do here, and we should design in allowances for future upgrades which implement these things and let it get done as a followon. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
On Mon, 16 Apr 2001, you wrote: > Mark Salisbury wrote: > > > > > Given a system speed, there is a repeating timer rate which will consume > > > 100% of the system in handling the timer interrupts. An attempt will > > > be made to detect this rate and adjust the timer to prevent system > > > lockup. This adjustment will look like timer overruns to the user > > > (i.e. we will take a percent of the interrupts and record the untaken > > > interrupts as overruns) > > > > just at first blush, there are some things in general but I need to read > > this again and more closely > > > > but, with POSIX timers, there is a nifty little restriction/protection built > > into the spec regarding the re-insertion of short interval repeating timers. > > that is: a repeating timer will not be re-inserted until AFTER the > > associated signal handler has been handled. > > Actually what it says is: "Only a single signal shall be queued to the > process for a given timer at any point in time. When a timer for which > a signal is still pending expires, no signal shall be queued, and a > timer overrun shall occur." > > It then goes on to talk about the overrun count and how it is to be > managed. > I guess I was confusing what the spec said with the way in which I chose to comply with the spec. I calculate overruns (I know when a timer went off, and how many of its intervals have passed since it went off by by time_since_expire/interval) and don't reinsert until return from the signal handler. this prevents a flood of high frequency interrupts inherently and allows processing of the signal handlers to proceed cleanly. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
On Mon, 16 Apr 2001, you wrote: Mark Salisbury wrote: Given a system speed, there is a repeating timer rate which will consume 100% of the system in handling the timer interrupts. An attempt will be made to detect this rate and adjust the timer to prevent system lockup. This adjustment will look like timer overruns to the user (i.e. we will take a percent of the interrupts and record the untaken interrupts as overruns) just at first blush, there are some things in general but I need to read this again and more closely but, with POSIX timers, there is a nifty little restriction/protection built into the spec regarding the re-insertion of short interval repeating timers. that is: a repeating timer will not be re-inserted until AFTER the associated signal handler has been handled. Actually what it says is: "Only a single signal shall be queued to the process for a given timer at any point in time. When a timer for which a signal is still pending expires, no signal shall be queued, and a timer overrun shall occur." It then goes on to talk about the overrun count and how it is to be managed. I guess I was confusing what the spec said with the way in which I chose to comply with the spec. I calculate overruns (I know when a timer went off, and how many of its intervals have passed since it went off by by time_since_expire/interval) and don't reinsert until return from the signal handler. this prevents a flood of high frequency interrupts inherently and allows processing of the signal handlers to proceed cleanly. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
e it is, adjusting CLOCK_UPTIME will cause the absolute times in the timer list to be handled properly without modifying them. (am I makeing myself clear? I will try to come up with a better description of what I mean) In either a ticked or tick less system, it is expected that resolutions higher than 1/HZ will come with some additional overhead. For this reason, the CLOCK resolution will be used to round up times for each timer. When the CLOCK provides 1/HZ (or coarser) resolution, the project will attempt to meet or exceed the current systems timer performance. ONLY in a ticked system. Safe guards: Given a system speed, there is a repeating timer rate which will consume 100% of the system in handling the timer interrupts. An attempt will be made to detect this rate and adjust the timer to prevent system lockup. This adjustment will look like timer overruns to the user (i.e. we will take a percent of the interrupts and record the untaken interrupts as overruns). see my earlier e-mail, although it is a simple matter to enforce a minimum allowable interval by parameter checking. What the project will NOT do: This project will NOT provide higher resolution accounting (i.e. user and system execution times). The project will NOT provide higher resolution VIRTUAL or PROFILE timers. as I said, there are some kool things we could do here, and we should design in allowances for future upgrades which implement these things and let it get done as a followon. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
> Given a system speed, there is a repeating timer rate which will consume > 100% of the system in handling the timer interrupts. An attempt will > be made to detect this rate and adjust the timer to prevent system > lockup. This adjustment will look like timer overruns to the user > (i.e. we will take a percent of the interrupts and record the untaken > interrupts as overruns) just at first blush, there are some things in general but I need to read this again and more closely but, with POSIX timers, there is a nifty little restriction/protection built into the spec regarding the re-insertion of short interval repeating timers. that is: a repeating timer will not be re-inserted until AFTER the associated signal handler has been handled. this has some interesting consequences for signal handling and signal delivery implementations, but importantly, it ensures that even a flood of POSIX timers with very short repeat intervals will be handled cleanly. I will get more detailed comments to you tomorrow. Mark Salisbury - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
all this talk about which data structure to use and how to allocate memory is wy premature. there needs to be a clear definition of the requirements that we wish to meet, including whether we are going to do ticked, tickless, or both a func spec, for lack of a better term needs to be developed then, when we go to design the thing, THEN is when we decide on the particular flavor of list/tree/heap/array/dbase that we use. let's engineer this thing instead of hacking it. On Sun, 15 Apr 2001, Jamie Lokier wrote: > Ben Greear wrote: > > > Note that jumping around the array thrashes no more cache than > > > traversing a tree (it touches the same number of elements). I prefer > > > heap-ordered trees though because fixed size is always a bad idea. > > > > With a tree, you will be allocating and de-allocating for every > > insert/delete right? > > No, there is no memory allocation. > > > On cache-coherency issues, wouldn't it be more likely to have a cache > > hit when you are accessing one contigious (ie the array) piece of > > memory? A 4-k page will hold a lot of indexes!! > > No, because when traversing an array-heap, you don't access contiguous > entries. You might get one or two more cache hits near the root of the > heap. > > > To get around the fixed size thing..could have > > the array grow itself when needed (and probably never shrink again). > > You could to that, but then you'd have to deal with memory allocation > failures and memory deadlocks, making add_timer rather complicated. > It's not acceptable for add_timer to fail or require kmalloc(). > > -- Jamie > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
all this talk about which data structure to use and how to allocate memory is wy premature. there needs to be a clear definition of the requirements that we wish to meet, including whether we are going to do ticked, tickless, or both a func spec, for lack of a better term needs to be developed then, when we go to design the thing, THEN is when we decide on the particular flavor of list/tree/heap/array/dbase that we use. let's engineer this thing instead of hacking it. On Sun, 15 Apr 2001, Jamie Lokier wrote: Ben Greear wrote: Note that jumping around the array thrashes no more cache than traversing a tree (it touches the same number of elements). I prefer heap-ordered trees though because fixed size is always a bad idea. With a tree, you will be allocating and de-allocating for every insert/delete right? No, there is no memory allocation. On cache-coherency issues, wouldn't it be more likely to have a cache hit when you are accessing one contigious (ie the array) piece of memory? A 4-k page will hold a lot of indexes!! No, because when traversing an array-heap, you don't access contiguous entries. You might get one or two more cache hits near the root of the heap. To get around the fixed size thing..could have the array grow itself when needed (and probably never shrink again). You could to that, but then you'd have to deal with memory allocation failures and memory deadlocks, making add_timer rather complicated. It's not acceptable for add_timer to fail or require kmalloc(). -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer!
Given a system speed, there is a repeating timer rate which will consume 100% of the system in handling the timer interrupts. An attempt will be made to detect this rate and adjust the timer to prevent system lockup. This adjustment will look like timer overruns to the user (i.e. we will take a percent of the interrupts and record the untaken interrupts as overruns) just at first blush, there are some things in general but I need to read this again and more closely but, with POSIX timers, there is a nifty little restriction/protection built into the spec regarding the re-insertion of short interval repeating timers. that is: a repeating timer will not be re-inserted until AFTER the associated signal handler has been handled. this has some interesting consequences for signal handling and signal delivery implementations, but importantly, it ensures that even a flood of POSIX timers with very short repeat intervals will be handled cleanly. I will get more detailed comments to you tomorrow. Mark Salisbury - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: POSIX 52 53? 54
these are covered in IEEE P100.13, D9 September 1997 AD212. it is available from IEEE for a "nominal" fee. they are 4 defined subsets of POSIX that are deemed appropriate for real-time systems. unfortunately, the sub in subset is a small delta from the full set. the subsets are: PSE51: Minimal Realtime System Profile PSE52: Realtime Controller System Profile PSE53: Dedicated Realtime System Profile PSE54: Multi-purpose Realtime System Profile. now, PSE51 is already about 90% of POSIX, so I don't really see what is so minimal about it. the others require even more. On Thu, 12 Apr 2001, [EMAIL PROTECTED] wrote: > POSIX 1003.13 defines profiles 51-4 where 51 is a single POSIX > process with multiple threads (RTLinux) and 54 is a full POSIX OS > with the RT extensions (Linux). > > On Thu, Apr 12, 2001 at 08:15:34PM -0700, george anzinger wrote: > > Any one know any thing about a POSIX draft 52 or 53 or 54. I think they > > are suppose to have something to do with real time. > > > > Where can they be found? What do they imply for the kernel? > > > > George > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > - > Victor Yodaiken > Finite State Machine Labs: The RTLinux Company. > www.fsmlabs.com www.rtlinux.com > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
> I think it makes the most sense to keep jiffie as a simple unsigned > int. If we leave drivers, and other code as is they can deal with > single word (32 bit) values and get reasonable results. If we make HZ > too high (say 10,000 to get micro second resolution) we will start > limiting the max time we can handle, in this case to about 71.5 hours. > (Actually 1/2 this value would start giving us trouble.) HZ only > affects the kernel internals (the user API is either seconds/micro > seconds or seconds/nano seconds). For those cases where we want a higer > resolution we just add a sub jiffie component. Another way of looking > at this is to set up HZ as the "normal" resolution. This would be the > resolution (as it is today) of the usual API calls. Only calls to the > POSIX 1b timers would be allowed to have higher resolution. I propose > that we use the POSIX standard to define "CLOCKS" with various > resolution, with the understanding that the higher resolutions will have > higher overhead. An yet another consideration, to get high resolution > with a reasonable maximum timer interval we will need to use two words > in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as > the high order part of the timer's time. > > Note that all of these considerations on jiffie size hold with or with > out a tick less system. inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
I think it makes the most sense to keep jiffie as a simple unsigned int. If we leave drivers, and other code as is they can deal with single word (32 bit) values and get reasonable results. If we make HZ too high (say 10,000 to get micro second resolution) we will start limiting the max time we can handle, in this case to about 71.5 hours. (Actually 1/2 this value would start giving us trouble.) HZ only affects the kernel internals (the user API is either seconds/micro seconds or seconds/nano seconds). For those cases where we want a higer resolution we just add a sub jiffie component. Another way of looking at this is to set up HZ as the "normal" resolution. This would be the resolution (as it is today) of the usual API calls. Only calls to the POSIX 1b timers would be allowed to have higher resolution. I propose that we use the POSIX standard to define "CLOCKS" with various resolution, with the understanding that the higher resolutions will have higher overhead. An yet another consideration, to get high resolution with a reasonable maximum timer interval we will need to use two words in the timer. I think it makes sense to use the jiffie (i.e. 1/HZ) as the high order part of the timer's time. Note that all of these considerations on jiffie size hold with or with out a tick less system. inner loop, i.e. interrupt timer code should never have to convert from some real time value into number of decrementer ticks in order to set up the next interrupt as that requires devides (and 64 bit ones at that) in a tickless system. this is why any variable interval list/heap/tree/whatever should be kept in local ticks. frequently used values can be pre-computed at boot time to speed up certain calculations (like how many local ticks/proc quantum) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: POSIX 52 53? 54
these are covered in IEEE P100.13, D9 September 1997 AD212. it is available from IEEE for a "nominal" fee. they are 4 defined subsets of POSIX that are deemed appropriate for real-time systems. unfortunately, the sub in subset is a small delta from the full set. the subsets are: PSE51: Minimal Realtime System Profile PSE52: Realtime Controller System Profile PSE53: Dedicated Realtime System Profile PSE54: Multi-purpose Realtime System Profile. now, PSE51 is already about 90% of POSIX, so I don't really see what is so minimal about it. the others require even more. On Thu, 12 Apr 2001, [EMAIL PROTECTED] wrote: POSIX 1003.13 defines profiles 51-4 where 51 is a single POSIX process with multiple threads (RTLinux) and 54 is a full POSIX OS with the RT extensions (Linux). On Thu, Apr 12, 2001 at 08:15:34PM -0700, george anzinger wrote: Any one know any thing about a POSIX draft 52 or 53 or 54. I think they are suppose to have something to do with real time. Where can they be found? What do they imply for the kernel? George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- - Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Wed, 11 Apr 2001, Bret Indrelee wrote: > Current generation PCs can easily handle 1000s of > interrupts a second if you keep the overhead small. the PC centric implementation of the ticked system is one of its major flaws. there are architectures which the cost of a fixed interval is the same as a variable interval, i.e. no reload register, so you must explicitely load a value each interrupt anyway. and if you want accurate intervals, you must perform a calculation each reload, and not just load a static value, because you don't know how many cycles it took from the time the interrupt happened till you get to the reload line because the int may have been masked or lower pri than another interrupt. also, why handle 1000's of interrupts if you only need to handle 10? -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Wed, 11 Apr 2001, Bret Indrelee wrote: Current generation PCs can easily handle 1000s of interrupts a second if you keep the overhead small. the PC centric implementation of the ticked system is one of its major flaws. there are architectures which the cost of a fixed interval is the same as a variable interval, i.e. no reload register, so you must explicitely load a value each interrupt anyway. and if you want accurate intervals, you must perform a calculation each reload, and not just load a static value, because you don't know how many cycles it took from the time the interrupt happened till you get to the reload line because the int may have been masked or lower pri than another interrupt. also, why handle 1000's of interrupts if you only need to handle 10? -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
> I suspect you might go for ticked if its overhead was less. The thing > that makes me think the overhead is high for tick less is the accounting > and time slice stuff. This has to be handled each system call and each > schedule call. These happen WAY more often than ticks... Contrary > wise, I would go for tick less if its overhead is the same or less under > a reasonable load. Of course, we would also want to check overload > sensitivity. as I said, i think the process time accounting is disjoint from the ticked/tickless issue and should therefore be considered seperately.. in my experience with the tickless method, after all pending timers have been serviced, then to determine the interval until the next interrupt should be generated all that is needed is one 64 bit subtraction and a register load (about 5 - 8 cycles) I think we should spend some serious time with some quick and dirty prototypes of both methods, both to characterize all the issues raised and to refine our ideas when it comes time to implement this. I also think that we should give some thought to implementing both an improved ticked system and a tickless system to be chosen as CONFIG options so that the developer putting together a system can make a choice based on their needs, and not our whims. I am more than willing to concede that there is a class of customer to whom a ticked system is appropriate, but I am quite sure that there is a class for whom the ticked model is completely unacceptable. > On a half way loaded system? Do you think it is that high? I sort of > think that, once the system is loaded, there would be a useful timer > tick most of the time. Might be useful to do some measurements of this. any non-useful tick takes away cycles that could be better used performing FFT's there are many kinds of loads, some which generate large numbers of timed events and some that generate none or few. I think we want to be able to provide good solutions for both cases even. we should do lots of measurements. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
I suspect you might go for ticked if its overhead was less. The thing that makes me think the overhead is high for tick less is the accounting and time slice stuff. This has to be handled each system call and each schedule call. These happen WAY more often than ticks... Contrary wise, I would go for tick less if its overhead is the same or less under a reasonable load. Of course, we would also want to check overload sensitivity. as I said, i think the process time accounting is disjoint from the ticked/tickless issue and should therefore be considered seperately.. in my experience with the tickless method, after all pending timers have been serviced, then to determine the interval until the next interrupt should be generated all that is needed is one 64 bit subtraction and a register load (about 5 - 8 cycles) I think we should spend some serious time with some quick and dirty prototypes of both methods, both to characterize all the issues raised and to refine our ideas when it comes time to implement this. I also think that we should give some thought to implementing both an improved ticked system and a tickless system to be chosen as CONFIG options so that the developer putting together a system can make a choice based on their needs, and not our whims. I am more than willing to concede that there is a class of customer to whom a ticked system is appropriate, but I am quite sure that there is a class for whom the ticked model is completely unacceptable. On a half way loaded system? Do you think it is that high? I sort of think that, once the system is loaded, there would be a useful timer tick most of the time. Might be useful to do some measurements of this. any non-useful tick takes away cycles that could be better used performing FFT's there are many kinds of loads, some which generate large numbers of timed events and some that generate none or few. I think we want to be able to provide good solutions for both cases even. we should do lots of measurements. Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
> mark salisbury wrote: > > > > george anzinger wrote: > > > > > f) As noted, the account timers (task user/system times) would be much > > > more accurate with the tick less approach. The cost is added code in > > > both the system call and the schedule path. > > > > > > Tentative conclusions: > > > > > > Currently we feel that the tick less approach is not acceptable due to > > > (f). We felt that this added code would NOT be welcome AND would, in a > > > reasonably active system, have much higher overhead than any savings in > > > not having a tick. Also (d) implies a list organization that will, at > > > the very least, be harder to understand. (We have some thoughts here, > > > but abandoned the effort because of (f).) We are, of course, open to > > > discussion on this issue and all others related to the project > > > objectives. > > > > f does not imply tick-less is not acceptable, it implies that better process time > > accounting is not acceptable. > > My thinking is that a timer implementation that forced (f) would have > problems gaining acceptance (even with me :). I think a tick less > system does force this and this is why we have, at least for the moment, > abandoned it. In no way does this preclude (f) as it is compatible with > either ticks or tick less time keeping. On the other hand, the stated > project objectives do not include (f) unless, of course we do a tick > less time system. > > > > list organization is not complex, it is a sorted absolute time list. I would > > argue that this is a hell of a lot easier to understand that ticks + offsets. > > The complexity comes in when you want to maintain indexes into the list > for quick insertion of new timers. To get the current insert > performance, for example, you would need pointers to (at least) each of > the next 256 centasecond boundaries in the list. But the list ages, so > these pointers need to be continually updated. The thought I had was to > update needed pointers (and only those needed) each time an insert was > done and a needed pointer was found to be missing or stale. Still it > adds complexity that the static structure used now doesn't have. actually, I think a head and tail pointer would be sufficient for most cases. (most new timers are either going to be a new head of list or a new tail, i.e. long duration timeouts that will never be serviced or short duration timers that are going to go off "real soon now (tm)") the oddball cases would be mostly coming from user-space, i.e. nanosleep which a longerr list insertion disapears in the block/wakeup/context switch overhead > > > > still, better process time accounting should be a compile CONFIG option, not > > ignored and ruled out because some one thinks that is is to expensive in the > > general case. > > As I said above, we are not ruling it out, but rather, we are not > requiring it by going tick less. > As I said, it is not clear how you could get > CONFIG_USELESS_PROCESS_TIME_ACCOUNTING unless you did a tick every > jiffie. What did you have in mind? time accounting can be limited to the quantum expiration and voluntary yields in the tickless/useless case. > For the most part, I agree. I am not sure that it makes a lot of sense > to mix some of these options, however. I think it comes down to the > question of benefit vs cost. If keeping an old version around that is > not any faster or more efficient in any way would seem too costly to > me. We would like to provide a system that is better in every way and > thus eliminate the need to keep the old one around. We could leave it > in as a compile option so folks would have a fall back, I suppose. I agree that some combinations don't make much sense _TO_ME_ but that doesn't mean they don't meet sombody's needs. in my case (embedded, medium hard real time, massively parallel multicomputer) the only choices that makes sense to my customers is tickless/useless in deployment and tickless/useful in development/profiling/optimization. in other cases ticked/useless makes sense (dumb old slow chips) I have no idea who would want ticked/useful or hybrid. i suggested hybrid as an alternative in case linus might be reluctant to gutting and replacing the sysclock. > > An Issue no one has raised is that the tick less system would need to > start a timer each time it scheduled a task. This would lead to either > slow but very precise time slicing or about what we have today with more > schedule overhead. no. you would re-use the timer with a new expiration time and a re-insert. also re overhead. the cost of servicing 10 times as many interrupts as necessary for system function must cost a fair chunk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
george anzinger wrote: > f) As noted, the account timers (task user/system times) would be much > more accurate with the tick less approach. The cost is added code in > both the system call and the schedule path. > > Tentative conclusions: > > Currently we feel that the tick less approach is not acceptable due to > (f). We felt that this added code would NOT be welcome AND would, in a > reasonably active system, have much higher overhead than any savings in > not having a tick. Also (d) implies a list organization that will, at > the very least, be harder to understand. (We have some thoughts here, > but abandoned the effort because of (f).) We are, of course, open to > discussion on this issue and all others related to the project > objectives. f does not imply tick-less is not acceptable, it implies that better process time accounting is not acceptable. list organization is not complex, it is a sorted absolute time list. I would argue that this is a hell of a lot easier to understand that ticks + offsets. still, better process time accounting should be a compile CONFIG option, not ignored and ruled out because some one thinks that is is to expensive in the general case. the whole point of linux and CONFIG options is to get you the kernel with the features you want, not what someone else wants. there should be a whole range of config options associated with this issue: CONFIG_JIFFIES == old jiffies implementation CONFIG_TICKLESS == tickless CONFIG_HYBRID == old jiffies plus a tickless high-res timer system on the side but not assoc w/ process and global timekeeping CONFIG_USELESS_PROCESS_TIME_ACCOUNTING = old style, cheap time acctg CONFIG_USEFUL_BUT_COSTS_TIME_ACCOUNTING = accurate but expensive time accounting this way, users who want tickless and lousy time acctg can have it AND people who want jiffies and good time acctg could have it. these features are largely disjoint and easily seperable. it is also relatively trivial to do this in such a way that drivers depending on the jiffie abstraction can be supported without modification no matter what the configuration. Mark Salisbury - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, Andi Kleen wrote: > Also generally the kernel has quite a lot of timers. are these generaly of the long interval, failure timeout type? i.e. 5 second device timeouts that are killed before they get executed because the device didn't timeout? if so, they have no effect on the number of timer interrupts because they generally never get hit. and when they do, you have to pay the price anyway. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, David Schleef wrote: > This just indicates that the interface needs to be richer -- i.e., > such as having a "lazy timer" that means: "wake me up when _at least_ > N ns have elapsed, but there's no hurry." If waking you up at N ns > is expensive, then the wakeup is delayed until something else > interesting happens. all POSIX timer and timer like functions (timer_xxx, nanosleep, alarm etc) are defined to operate on a 'no earlier than' semantic. i.e. if you ask to nanosleep for 500 nsec, you will sleep for no less than 500 nanoseconds, but possibly up to 20,000,500 nanoseconds. this is because the maximum legal POSIX time resolution is 20,000,000 nanoseconds (1/50th second or 50hz because of european electricity and old hardware) -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, Alan Cox wrote: > > Does not sound very attractive all at all on non virtual machines (I see the point >on > > UML/VM): > > making system entry/context switch/interrupts slower, making add_timer slower, >just to > > process a few less timer interrupts. That's like robbing the fast paths for a slow >path. > > Measure the number of clocks executing a timer interrupt. rdtsc is fast. Now > consider the fact that out of this you get KHz or better scheduling > resolution required for games and midi. I'd say it looks good. I agree > the accounting of user/system time needs care to avoid slowing down syscall > paths > > Alan the system I implemented this in went from 25 Millisecond resolution to 25-60 Nanosecond resolution (depending on the CPU underneath). that is a theoretical factor of 500,000 to 1,000,000 improvement in resolution for timed events, and the clock overhead after the change was about the same. (+-10% depending on underlying CPU) this is on a system that only had one clock tick per process quantum, as opposed to the 10 in linux. -- /*--------** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, David Schleef wrote: > i.e., the TSC, you have to use 8254 timer 0 as both the timebase > and the interval counter -- you end up slowly losing time because > of the race condition between reading the timer and writing a > new interval. actually, I have an algorithm to fix that. (had to implement this on a system with a single 32 bit decrementer (an ADI21060 SHARC, YUK!)) the algorithm simulates a free spinning 64 bit incrementer given a 32 bit interrupting decrementer under exclusive control of the timekeeping code. it also takes into account the read/calculate/write interval. > It would be nice to see any redesign in this area make it more > modular. I have hardware that would make it possible to slave > the Linux system clock directly off a high-accuracy timebase, > which would be super-useful for some applications. I've been > doing some of this already, both as a kernel patch and as part > of RTAI; search for 'timekeeper' in the LKML archives if interested. > > > > > dave... -- /*--------** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, Martin Mares wrote: > Except for machines with very slow timers we really should account time > to processes during context switch instead of sampling on timer ticks. > The current values are in many situations (i.e., lots of processes > or a process frequently waiting for events bound to timer) a pile > of random numbers. yup. however, there is a performance penalty even on fast machines for the fine grained process time usage accounting, and it in the past there has been a strong reluctance to add overhead to syscalls and other context switches. It would probably be a good compile config option to allow fine or coarse process time accounting, that leaves the choice to the person setting up the system to make the choice based on their needs. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, 09 Apr 2001, Alan Cox wrote: > > Its worth doing even on the ancient x86 boards with the PIT. It does require > some driver changes since > > > while(time_before(jiffies, we_explode)) > poll_things(); > > no longer works jiffies could be replaced easily enough w/ a macro such as #define jiffies (get_time_in_jiffies()) then driver code would not need to be touched. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
which kind of U/K accaounting are you referring to? are you referring to global changes in world time? are you referring to time used by a process? I think the reduction of clock interrupts by a factor of 10 would buy us some performance margin that could be traded for a slightly more complex handler. On Tue, 10 Apr 2001, Andi Kleen wrote: > On Mon, Apr 09, 2001 at 02:19:28PM -0400, Mark Salisbury wrote: > > this is one of linux biggest weaknesses. the fixed interval timer is a > > throwback. it should be replaced with a variable interval timer with interrupts > > on demand for any system with a cpu sane/modern enough to have an on-chip > > interrupting decrementer. (i.e just about any modern chip) > > Just how would you do kernel/user CPU time accounting then ? It's currently done > on every timer tick, and doing it less often would make it useless. > > > -Andi > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
which kind of U/K accaounting are you referring to? are you referring to global changes in world time? are you referring to time used by a process? I think the reduction of clock interrupts by a factor of 10 would buy us some performance margin that could be traded for a slightly more complex handler. On Tue, 10 Apr 2001, Andi Kleen wrote: On Mon, Apr 09, 2001 at 02:19:28PM -0400, Mark Salisbury wrote: this is one of linux biggest weaknesses. the fixed interval timer is a throwback. it should be replaced with a variable interval timer with interrupts on demand for any system with a cpu sane/modern enough to have an on-chip interrupting decrementer. (i.e just about any modern chip) Just how would you do kernel/user CPU time accounting then ? It's currently done on every timer tick, and doing it less often would make it useless. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, 09 Apr 2001, Alan Cox wrote: Its worth doing even on the ancient x86 boards with the PIT. It does require some driver changes since while(time_before(jiffies, we_explode)) poll_things(); no longer works jiffies could be replaced easily enough w/ a macro such as #define jiffies (get_time_in_jiffies()) then driver code would not need to be touched. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, Martin Mares wrote: Except for machines with very slow timers we really should account time to processes during context switch instead of sampling on timer ticks. The current values are in many situations (i.e., lots of processes or a process frequently waiting for events bound to timer) a pile of random numbers. yup. however, there is a performance penalty even on fast machines for the fine grained process time usage accounting, and it in the past there has been a strong reluctance to add overhead to syscalls and other context switches. It would probably be a good compile config option to allow fine or coarse process time accounting, that leaves the choice to the person setting up the system to make the choice based on their needs. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, David Schleef wrote: i.e., the TSC, you have to use 8254 timer 0 as both the timebase and the interval counter -- you end up slowly losing time because of the race condition between reading the timer and writing a new interval. actually, I have an algorithm to fix that. (had to implement this on a system with a single 32 bit decrementer (an ADI21060 SHARC, YUK!)) the algorithm simulates a free spinning 64 bit incrementer given a 32 bit interrupting decrementer under exclusive control of the timekeeping code. it also takes into account the read/calculate/write interval. It would be nice to see any redesign in this area make it more modular. I have hardware that would make it possible to slave the Linux system clock directly off a high-accuracy timebase, which would be super-useful for some applications. I've been doing some of this already, both as a kernel patch and as part of RTAI; search for 'timekeeper' in the LKML archives if interested. dave... -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, Alan Cox wrote: Does not sound very attractive all at all on non virtual machines (I see the point on UML/VM): making system entry/context switch/interrupts slower, making add_timer slower, just to process a few less timer interrupts. That's like robbing the fast paths for a slow path. Measure the number of clocks executing a timer interrupt. rdtsc is fast. Now consider the fact that out of this you get KHz or better scheduling resolution required for games and midi. I'd say it looks good. I agree the accounting of user/system time needs care to avoid slowing down syscall paths Alan the system I implemented this in went from 25 Millisecond resolution to 25-60 Nanosecond resolution (depending on the CPU underneath). that is a theoretical factor of 500,000 to 1,000,000 improvement in resolution for timed events, and the clock overhead after the change was about the same. (+-10% depending on underlying CPU) this is on a system that only had one clock tick per process quantum, as opposed to the 10 in linux. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, David Schleef wrote: This just indicates that the interface needs to be richer -- i.e., such as having a "lazy timer" that means: "wake me up when _at least_ N ns have elapsed, but there's no hurry." If waking you up at N ns is expensive, then the wakeup is delayed until something else interesting happens. all POSIX timer and timer like functions (timer_xxx, nanosleep, alarm etc) are defined to operate on a 'no earlier than' semantic. i.e. if you ask to nanosleep for 500 nsec, you will sleep for no less than 500 nanoseconds, but possibly up to 20,000,500 nanoseconds. this is because the maximum legal POSIX time resolution is 20,000,000 nanoseconds (1/50th second or 50hz because of european electricity and old hardware) -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, 10 Apr 2001, Andi Kleen wrote: Also generally the kernel has quite a lot of timers. are these generaly of the long interval, failure timeout type? i.e. 5 second device timeouts that are killed before they get executed because the device didn't timeout? if so, they have no effect on the number of timer interrupts because they generally never get hit. and when they do, you have to pay the price anyway. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
george anzinger wrote: f) As noted, the account timers (task user/system times) would be much more accurate with the tick less approach. The cost is added code in both the system call and the schedule path. Tentative conclusions: Currently we feel that the tick less approach is not acceptable due to (f). We felt that this added code would NOT be welcome AND would, in a reasonably active system, have much higher overhead than any savings in not having a tick. Also (d) implies a list organization that will, at the very least, be harder to understand. (We have some thoughts here, but abandoned the effort because of (f).) We are, of course, open to discussion on this issue and all others related to the project objectives. f does not imply tick-less is not acceptable, it implies that better process time accounting is not acceptable. list organization is not complex, it is a sorted absolute time list. I would argue that this is a hell of a lot easier to understand that ticks + offsets. still, better process time accounting should be a compile CONFIG option, not ignored and ruled out because some one thinks that is is to expensive in the general case. the whole point of linux and CONFIG options is to get you the kernel with the features you want, not what someone else wants. there should be a whole range of config options associated with this issue: CONFIG_JIFFIES == old jiffies implementation CONFIG_TICKLESS == tickless CONFIG_HYBRID == old jiffies plus a tickless high-res timer system on the side but not assoc w/ process and global timekeeping CONFIG_USELESS_PROCESS_TIME_ACCOUNTING = old style, cheap time acctg CONFIG_USEFUL_BUT_COSTS_TIME_ACCOUNTING = accurate but expensive time accounting this way, users who want tickless and lousy time acctg can have it AND people who want jiffies and good time acctg could have it. these features are largely disjoint and easily seperable. it is also relatively trivial to do this in such a way that drivers depending on the jiffie abstraction can be supported without modification no matter what the configuration. Mark Salisbury - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
mark salisbury wrote: george anzinger wrote: f) As noted, the account timers (task user/system times) would be much more accurate with the tick less approach. The cost is added code in both the system call and the schedule path. Tentative conclusions: Currently we feel that the tick less approach is not acceptable due to (f). We felt that this added code would NOT be welcome AND would, in a reasonably active system, have much higher overhead than any savings in not having a tick. Also (d) implies a list organization that will, at the very least, be harder to understand. (We have some thoughts here, but abandoned the effort because of (f).) We are, of course, open to discussion on this issue and all others related to the project objectives. f does not imply tick-less is not acceptable, it implies that better process time accounting is not acceptable. My thinking is that a timer implementation that forced (f) would have problems gaining acceptance (even with me :). I think a tick less system does force this and this is why we have, at least for the moment, abandoned it. In no way does this preclude (f) as it is compatible with either ticks or tick less time keeping. On the other hand, the stated project objectives do not include (f) unless, of course we do a tick less time system. list organization is not complex, it is a sorted absolute time list. I would argue that this is a hell of a lot easier to understand that ticks + offsets. The complexity comes in when you want to maintain indexes into the list for quick insertion of new timers. To get the current insert performance, for example, you would need pointers to (at least) each of the next 256 centasecond boundaries in the list. But the list ages, so these pointers need to be continually updated. The thought I had was to update needed pointers (and only those needed) each time an insert was done and a needed pointer was found to be missing or stale. Still it adds complexity that the static structure used now doesn't have. actually, I think a head and tail pointer would be sufficient for most cases. (most new timers are either going to be a new head of list or a new tail, i.e. long duration timeouts that will never be serviced or short duration timers that are going to go off "real soon now (tm)") the oddball cases would be mostly coming from user-space, i.e. nanosleep which a longerr list insertion disapears in the block/wakeup/context switch overhead still, better process time accounting should be a compile CONFIG option, not ignored and ruled out because some one thinks that is is to expensive in the general case. As I said above, we are not ruling it out, but rather, we are not requiring it by going tick less. As I said, it is not clear how you could get CONFIG_USELESS_PROCESS_TIME_ACCOUNTING unless you did a tick every jiffie. What did you have in mind? time accounting can be limited to the quantum expiration and voluntary yields in the tickless/useless case. For the most part, I agree. I am not sure that it makes a lot of sense to mix some of these options, however. I think it comes down to the question of benefit vs cost. If keeping an old version around that is not any faster or more efficient in any way would seem too costly to me. We would like to provide a system that is better in every way and thus eliminate the need to keep the old one around. We could leave it in as a compile option so folks would have a fall back, I suppose. I agree that some combinations don't make much sense _TO_ME_ but that doesn't mean they don't meet sombody's needs. in my case (embedded, medium hard real time, massively parallel multicomputer) the only choices that makes sense to my customers is tickless/useless in deployment and tickless/useful in development/profiling/optimization. in other cases ticked/useless makes sense (dumb old slow chips) I have no idea who would want ticked/useful or hybrid. i suggested hybrid as an alternative in case linus might be reluctant to gutting and replacing the sysclock. An Issue no one has raised is that the tick less system would need to start a timer each time it scheduled a task. This would lead to either slow but very precise time slicing or about what we have today with more schedule overhead. no. you would re-use the timer with a new expiration time and a re-insert. also re overhead. the cost of servicing 10 times as many interrupts as necessary for system function must cost a fair chunk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, 09 Apr 2001, Alan Cox wrote: > > this is one of linux biggest weaknesses. the fixed interval timer is a > > throwback. it should be replaced with a variable interval timer with interrupts > > on demand for any system with a cpu sane/modern enough to have an on-chip > > interrupting decrementer. (i.e just about any modern chip) > > Its worth doing even on the ancient x86 boards with the PIT. It does require > some driver changes since > > > while(time_before(jiffies, we_explode)) > poll_things(); > > no longer works > It would be great if this could be one of the 2.5 goals/projects. it would make all sorts of fun and useful timed event services easier to implement and provide (potentially) microsecond resolution as opposed to the current 10Ms. plus, we would only get one "sysclock" timer interrupt per process quantum instead of 10. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
this is one of linux biggest weaknesses. the fixed interval timer is a throwback. it should be replaced with a variable interval timer with interrupts on demand for any system with a cpu sane/modern enough to have an on-chip interrupting decrementer. (i.e just about any modern chip) On Mon, 09 Apr 2001, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > I have a suggestion that might seem unusual at first but it is > > important for Linux on S/390. We are facing the problem that we want > > to start many (> 1000) Linux images on a big S/390 machine. Every > > image has its own 100 HZ timer on every processor the images uses > > (normally 1). On a single image system the processor use of the 100 HZ > > timer is not a big deal but with > 1000 images you need a lot of > > processing power just to execute the 100 HZ timers. You quickly end up > > with 100% CPU only for the timer interrupts of otherwise idle images. > > This is going to be a problem for UML as well, and I was considering something > very similar. I did a quick scan of your prose, and the description sounds > like what I had in mind. > > So, count me in as a supporter of this. > > A small request: Since S/390 is not the only port that needs this, I'd be > happy if it was made as generic as possible (and it may already be, I haven't > gone through the code yet). > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
this is one of linux biggest weaknesses. the fixed interval timer is a throwback. it should be replaced with a variable interval timer with interrupts on demand for any system with a cpu sane/modern enough to have an on-chip interrupting decrementer. (i.e just about any modern chip) On Mon, 09 Apr 2001, Jeff Dike wrote: [EMAIL PROTECTED] said: I have a suggestion that might seem unusual at first but it is important for Linux on S/390. We are facing the problem that we want to start many ( 1000) Linux images on a big S/390 machine. Every image has its own 100 HZ timer on every processor the images uses (normally 1). On a single image system the processor use of the 100 HZ timer is not a big deal but with 1000 images you need a lot of processing power just to execute the 100 HZ timers. You quickly end up with 100% CPU only for the timer interrupts of otherwise idle images. This is going to be a problem for UML as well, and I was considering something very similar. I did a quick scan of your prose, and the description sounds like what I had in mind. So, count me in as a supporter of this. A small request: Since S/390 is not the only port that needs this, I'd be happy if it was made as generic as possible (and it may already be, I haven't gone through the code yet). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, 09 Apr 2001, Alan Cox wrote: this is one of linux biggest weaknesses. the fixed interval timer is a throwback. it should be replaced with a variable interval timer with interrupts on demand for any system with a cpu sane/modern enough to have an on-chip interrupting decrementer. (i.e just about any modern chip) Its worth doing even on the ancient x86 boards with the PIT. It does require some driver changes since while(time_before(jiffies, we_explode)) poll_things(); no longer works It would be great if this could be one of the 2.5 goals/projects. it would make all sorts of fun and useful timed event services easier to implement and provide (potentially) microsecond resolution as opposed to the current 10Ms. plus, we would only get one "sysclock" timer interrupt per process quantum instead of 10. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** I will be riding in the Multiple Sclerosis** ** Great Mass Getaway, a 150 mile bike ride from ** ** Boston to Provincetown. Last year I raised ** ** over $1200. This year I would like to beat ** ** that. If you would like to contribute, ** ** please contact me.** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
On Fri, 27 Oct 2000, Jason Wohlgemuth wrote: > Consider this: > > A subsystem that is statically built into the Linux Kernel is modified > to allow the registration of a structure containing function pointers. > > The function pointers corrolate to a set of functions within that subsystem. > If the new structure of pointers has been registered, the original > functions will call the new functions in the structure passing all > arguments and returning the return value of the new function. > > With this said, if no structure has been registered, then no > functionality is degraded within the kernel. Only the loss of some cpu > time to check the pointers at the top of the old functions. > > Now, if a module is loaded that registers a set of functions that have > increased functionality compared to the original functions, if that > modules is not based off GPL'd code, must the source code of that module > be released under the GPL? > > Thanks in advance, > Jason Wohlgemuth the api of the module would be a reimplementation of a GPL'd api (the function names may have changed, but the base behaviors must be equivalent) so the question in simple terms might phrased as: is the API under GPL, or is it the code or are both? I think the answer is both. -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: GPL Question
On Fri, 27 Oct 2000, Jason Wohlgemuth wrote: Consider this: A subsystem that is statically built into the Linux Kernel is modified to allow the registration of a structure containing function pointers. The function pointers corrolate to a set of functions within that subsystem. If the new structure of pointers has been registered, the original functions will call the new functions in the structure passing all arguments and returning the return value of the new function. With this said, if no structure has been registered, then no functionality is degraded within the kernel. Only the loss of some cpu time to check the pointers at the top of the old functions. Now, if a module is loaded that registers a set of functions that have increased functionality compared to the original functions, if that modules is not based off GPL'd code, must the source code of that module be released under the GPL? Thanks in advance, Jason Wohlgemuth the api of the module would be a reimplementation of a GPL'd api (the function names may have changed, but the base behaviors must be equivalent) so the question in simple terms might phrased as: is the API under GPL, or is it the code or are both? I think the answer is both. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On Tue, 17 Oct 2000, David Weinehall wrote: > On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote: > > > > On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote: > > > On Tue, 17 Oct 2000, Mikael Pettersson wrote: > > > > > Why Intel chose family 15 is still beyond me though. > > > > IV is 15 if you just translate the symbols, but ignore the meaning > > either that or someone was smoking alot of crack. > > Huh? IV == 4. XV == 15. > > I = 1, V = 5, X = 10, L = 50, C = 100, D = 500, M = 1000... > > Unless you translate the signs one by one. But that's not the correct > way to do it. see the qualifyer in my statement: "...if you just translate the symbols, but ignore the meaning..." of course that is not the right way to do it, when has that ever stopped intel? -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On Tue, 17 Oct 2000, David Weinehall wrote: On Tue, Oct 17, 2000 at 08:14:58AM -0400, Mark Salisbury wrote: On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote: On Tue, 17 Oct 2000, Mikael Pettersson wrote: Why Intel chose family 15 is still beyond me though. IV is 15 if you just translate the symbols, but ignore the meaning either that or someone was smoking alot of crack. Huh? IV == 4. XV == 15. I = 1, V = 5, X = 10, L = 50, C = 100, D = 500, M = 1000... Unless you translate the signs one by one. But that's not the correct way to do it. see the qualifyer in my statement: "...if you just translate the symbols, but ignore the meaning..." of course that is not the right way to do it, when has that ever stopped intel? -- /*----** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote: > On Tue, 17 Oct 2000, Mikael Pettersson wrote: > Why Intel chose family 15 is still beyond me though. IV is 15 if you just translate the symbols, but ignore the meaning either that or someone was smoking alot of crack. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On Mon, 16 Oct 2000, [EMAIL PROTECTED] wrote: On Tue, 17 Oct 2000, Mikael Pettersson wrote: Why Intel chose family 15 is still beyond me though. IV is 15 if you just translate the symbols, but ignore the meaning either that or someone was smoking alot of crack. -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism]C++ Flamewar
didn't say I wanted to do it, just that it could be done. my point was that a god-awful 365 message flamewar was unnecessary, and removing C++ keywords from system headers is not that big a deal. On Mon, 16 Oct 2000, Keith Owens wrote: > On Mon, 16 Oct 2000 08:50:24 -0400, > Mark Salisbury <[EMAIL PROTECTED]> wrote: > >the original-original post was somebody asking why not make the kernel headers > >C++ friendly. > >all he wanted was the c++ reserved words removed from / kept out of the headers. > >that way, if they for some reason want to write, or maybe proto a MODULE in c++ > >they could. no reference to putting C++ in the kernel, just writing a module > >in it. to me this means that the MODULE would have to be linked w/ libg++ > >_NOT_ the kernel. > > Interesting concept, linking a module with libg++. Would that be a > dynamic or static link? > > If it is dynamic then you can absolutely forget about loading the > module into the kernel, there is no way that modutils will ever support > that. If it is a static link then every module has its own private > copy of libg++, that would introduce more than a little kernel bloat. > How big is a static copy of libg++ these days? The thought of two or > more modules each with a static copy of libg++ but running in the same > kernel address space gives me the shivers. > > So even if you can compile a module with C++ headers and link against > libg++, it is extremely unlikely that you could load it. If you cannot > load it, why bother compiling it with C++? > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- /*** ** Mark Salisbury | Mercury Computer Systems** ** [EMAIL PROTECTED] | System OS - Kernel Team ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism]C++ Flamewar
On Mon, 16 Oct 2000, Igmar Palsenberg wrote: > On Mon, 16 Oct 2000, Jeff V. Merkey wrote: > > On Mon, 16 Oct 2000, Generic Kernel Geek wrote: > > > > C++ sucks for kernel dev, because I say it does. the original-original post was somebody asking why not make the kernel headers C++ friendly. all he wanted was the c++ reserved words removed from / kept out of the headers. that way, if they for some reason want to write, or maybe proto a MODULE in c++ they could. no reference to putting C++ in the kernel, just writing a module in it. to me this means that the MODULE would have to be linked w/ libg++ _NOT_ the kernel. only his module and its users and would have to pay this price. no need for a flame war, all that needed to be said was "sorry, we dont currently support it and I have too much work already, but if you want to develop a patch..." instead this turned into a "you suck for even thinking it" flamewar. p.s. there are lots of examples of kernels written mainly in c++ that work quite nicely, and most of them are LESS than 7 years old. see the OSF's MK++ (a C++ black box Mach re-implementation), ECOS, BEOS (all except the core of the kernel) etc etc... -- /*--------** ** Mark Salisbury |[EMAIL PROTECTED] ** **** ** "WYGIWYD - What You Get Is What You Deserve" ** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
problem with cscope and 2.4-test8 source file
I use cscope version 13.7 (on solaris 2.6)
the source file linux/fs/hpfs/super.c
from kernel version 2.4-test8 causes cscope to core dump during the database
generation phase.
the problem is the extremely long printk() string starting on line 280 in the
function static inline void hpfs_help(void){}
simply breaking up this printk up into several smaller printk's solves the
problem.
I guess this is only a problem if you use cscope, but I thought you all would
like to know..
Mark
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** "WYGIWYD - What You Get Is What You Deserve" **
***/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
problem with cscope and 2.4-test8 source file
I use cscope version 13.7 (on solaris 2.6)
the source file linux/fs/hpfs/super.c
from kernel version 2.4-test8 causes cscope to core dump during the database
generation phase.
the problem is the extremely long printk() string starting on line 280 in the
function static inline void hpfs_help(void){}
simply breaking up this printk up into several smaller printk's solves the
problem.
I guess this is only a problem if you use cscope, but I thought you all would
like to know..
Mark
/***
** Mark Salisbury | Mercury Computer Systems**
** [EMAIL PROTECTED] | System OS - Kernel Team **
****
** "WYGIWYD - What You Get Is What You Deserve" **
***/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
