Re: [PATCH] 2.2.18pre13: Small patches from Andrea
On Mon, Oct 02, 2000 at 10:29:50PM +0100, Alan Cox wrote: > Im intentionally avoiding these right now. The 2.2.18 kernel has a very large > amount of updates to drivers/extra functionality. I don't want to mix any of > that with core internal changes of any kind. The VM fixes in paticular look > good but would be an invitation to disaster to merge this release. OTOH -- Andrea's patches have been around pretty long time; maybe it's time to have them added once in one release, test them (in fact many people have tested several patches for long time as SuSE's set comes standard with several of them out of the box) so that this backlog is killed ? Just a thought... -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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: [PATCH] 2.2.18pre13: Small patches from Andrea
On Mon, Oct 02, 2000 at 10:29:50PM +0100, Alan Cox wrote: Im intentionally avoiding these right now. The 2.2.18 kernel has a very large amount of updates to drivers/extra functionality. I don't want to mix any of that with core internal changes of any kind. The VM fixes in paticular look good but would be an invitation to disaster to merge this release. OTOH -- Andrea's patches have been around pretty long time; maybe it's time to have them added once in one release, test them (in fact many people have tested several patches for long time as SuSE's set comes standard with several of them out of the box) so that this backlog is killed ? Just a thought... -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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: [PATCH] 2.2.18pre13: Small patches from Andrea
> I suppose I should let Andrea submit these, but he has such a huge > patch collection (thank you!) that I thought it might be useful to > pick out some of the smaller ones that would be less controversial > for inclusion in the main kernel. Im intentionally avoiding these right now. The 2.2.18 kernel has a very large amount of updates to drivers/extra functionality. I don't want to mix any of that with core internal changes of any kind. The VM fixes in paticular look good but would be an invitation to disaster to merge this release. Alan - 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/
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec >= 100) {
- sec += 1;
- usec -= 100;
- }
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(_lock, flags);
- while (usec >= 100) {
- usec -= 100;
- sec++;
- }
-
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv->tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv->tv_usec >= 100) {
- tv->tv_usec -= 100;
- tv->tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/linux/time.h:1.1.14.1
--- linux/include/linux/time.h:1.1 Thu Jul 6 22:04:59 2000
+++
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli [EMAIL PROTECTED]
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec = 100) {
- sec += 1;
- usec -= 100;
- }
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(xtime_lock, flags);
- while (usec = 100) {
- usec -= 100;
- sec++;
- }
-
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv-tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv-tv_usec = 100) {
- tv-tv_usec -= 100;
- tv-tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/linux/time.h:1.1.14.1
--- linux/include/linux/time.h:1.1 Thu Jul 6 22:04:59 2000
+++ linux/include/linux/time.h Wed
Re: [PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge patch collection (thank you!) that I thought it might be useful to pick out some of the smaller ones that would be less controversial for inclusion in the main kernel. Im intentionally avoiding these right now. The 2.2.18 kernel has a very large amount of updates to drivers/extra functionality. I don't want to mix any of that with core internal changes of any kind. The VM fixes in paticular look good but would be an invitation to disaster to merge this release. Alan - 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/
