On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote:
> b) add a new boot option telling the kernel the name of some file in
> initrd or similar from which to load additional options.
a file in initrd isn't a good choice; as the initrd is generally a fix
image
the point is some
On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote:
> Well, we have initramfs for the really big stuff. The kernel
> shouldn't really need that much data, though.
except the initrd image is in many cases fairly fixed; right now i
have options i pass into initramfs by passing
On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
> Maybe not. Another option would simply be to bump it up
> significantly (2x isn't really that much.) 4096, maybe.
I wonder if we're not at the point where we need something different
to what we have now. The concept of a
On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:
> I think someone on the SYSLINUX mailing list already sent a patch to
> akpm to make 512 the default; making it configurable would be a
> better idea. Feel free to send your patch through me.
So we really need this to be a
On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:
I think someone on the SYSLINUX mailing list already sent a patch to
akpm to make 512 the default; making it configurable would be a
better idea. Feel free to send your patch through me.
So we really need this to be a
On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
Maybe not. Another option would simply be to bump it up
significantly (2x isn't really that much.) 4096, maybe.
I wonder if we're not at the point where we need something different
to what we have now. The concept of a
On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote:
Well, we have initramfs for the really big stuff. The kernel
shouldn't really need that much data, though.
except the initrd image is in many cases fairly fixed; right now i
have options i pass into initramfs by passing arguments
On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote:
b) add a new boot option telling the kernel the name of some file in
initrd or similar from which to load additional options.
a file in initrd isn't a good choice; as the initrd is generally a fix
image
the point is some bootloaders
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
> Why don't you do some research on manners?
It was (an obvious) troll. Don't take it so seriously. Besides, deep
deep down I really am a terrible person.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote:
> I know that experience dosen't come from packing the kernel source,
> or the zillion other tar archives on the internet.
Are you deliberately trying to be annoying? Let me guess:
- your under 25 years of age, probably in high
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote:
I know that experience dosen't come from packing the kernel source,
or the zillion other tar archives on the internet.
Are you deliberately trying to be annoying? Let me guess:
- your under 25 years of age, probably in high
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
Why don't you do some research on manners?
It was (an obvious) troll. Don't take it so seriously. Besides, deep
deep down I really am a terrible person.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote:
> The purpose of the patch is to overmount ramfs/rootfs with tmpfs before
> the compressed cpio archive is unpacked and /init is run.
yes and no
there are people who want the overmount even without cpio
decompression
> But, it's
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote:
> Overmount_rootfs shouldn't take place until you know for sure the
> kernel detects an initramfs.
Actually, it was a deliberate decision to *always* overmount after
some discussion with people.
It's not a clean solution and the
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote:
> I'm curious as to why the kernel has to include the decoder - why
> you can't just run a self-extracting executable in an empty
> initramfs (with a preset capacity if needs be).
You could do tht right now if you wished.
We just
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote:
> What if you have a root.cpio.gz that requires 200MB to hold, but you
> only have 300MB of memory?
then it won't work with nay of the schemes you've suggested
> 50% of total memory wouldn't hold it, but 90% etc. would
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote:
> Wouldn't it be better to put overmount_rootfs in initramfs.c
> and call it only if there's a initramfs?
I don't see what or how that helps. Yes we can shuffle some code
about but the real problem still exists.
That is is that
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote:
Wouldn't it be better to put overmount_rootfs in initramfs.c
and call it only if there's a initramfs?
I don't see what or how that helps. Yes we can shuffle some code
about but the real problem still exists.
That is is that
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote:
What if you have a root.cpio.gz that requires 200MB to hold, but you
only have 300MB of memory?
then it won't work with nay of the schemes you've suggested
50% of total memory wouldn't hold it, but 90% etc. would
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote:
I'm curious as to why the kernel has to include the decoder - why
you can't just run a self-extracting executable in an empty
initramfs (with a preset capacity if needs be).
You could do tht right now if you wished.
We just
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote:
Overmount_rootfs shouldn't take place until you know for sure the
kernel detects an initramfs.
Actually, it was a deliberate decision to *always* overmount after
some discussion with people.
It's not a clean solution and the
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote:
The purpose of the patch is to overmount ramfs/rootfs with tmpfs before
the compressed cpio archive is unpacked and /init is run.
yes and no
there are people who want the overmount even without cpio
decompression
But, it's only
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
> I don't know, because tar is probably more widely used and
> consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
> Right, but it would be nice to have that option if initramfs
> using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
Right, but it would be nice to have that option if initramfs
using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
I don't know, because tar is probably more widely used and
consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
> Also, tar should be an option instead of cpio for the archiver,
> because tar is more widely used.
pretty much everyone will have cpio and it's format is much
simpler/cleaner to deal with
if we want vastly more complex
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote:
> I tried it with kernel 2.6.13-rc5 and it seems to work.
it should yes
> It uses 50% of total memory for tmpfs, but it would be nice to have
> an option (tmpfs_size=90% etc.) that you could pass to the kernel.
that's just
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote:
[...]
> +Dell OpenManage requires this driver on the following Dell PowerEdge systems:
> +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC,
> +700, and 750. Other Dell software such as the open source
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
> Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote:
[...]
+Dell OpenManage requires this driver on the following Dell PowerEdge systems:
+300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC,
+700, and 750. Other Dell software such as the open source Libsmbios
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote:
I tried it with kernel 2.6.13-rc5 and it seems to work.
it should yes
It uses 50% of total memory for tmpfs, but it would be nice to have
an option (tmpfs_size=90% etc.) that you could pass to the kernel.
that's just because
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
Also, tar should be an option instead of cpio for the archiver,
because tar is more widely used.
pretty much everyone will have cpio and it's format is much
simpler/cleaner to deal with
if we want vastly more complex
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote:
> I was just making a suggestion to whoever it may concern, because I
> think it would extend the usefullness of initramfs.
I have a path for initramfs to use tmpfs. It's sorta hacky so I never
submitted it and solves a niche
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote:
I was just making a suggestion to whoever it may concern, because I
think it would extend the usefullness of initramfs.
I have a path for initramfs to use tmpfs. It's sorta hacky so I never
submitted it and solves a niche
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
> The parameter value should IMHO be a pointer to a struct {
> unsigned long long maxspeed; // (with 0 being the magic max. value?)
> int facility; /* 0=general speed, 2=general read, 4=read data,
> 6=read audio,
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
The parameter value should IMHO be a pointer to a struct {
unsigned long long maxspeed; // (with 0 being the magic max. value?)
int facility; /* 0=general speed, 2=general read, 4=read data,
6=read audio, 8=read
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote:
> Another annoying problem is that once the system reaches this 2GB
> limit, then every process which exits will receive a signal,
> SIGXFSZ. This signal is generated because an attempt was made to
> write beyond the limit for
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote:
Another annoying problem is that once the system reaches this 2GB
limit, then every process which exits will receive a signal,
SIGXFSZ. This signal is generated because an attempt was made to
write beyond the limit for the
On Thu, Aug 18, 2005 at 11:03:45PM -0700, Howard Chu wrote:
> If the 2.6 kernel makes this programming model unreasonably slow,
> then quite simply this kernel is not viable as a database platform.
Pretty much everyone else manages to make it work.
-
To unsubscribe from this list: send the line
On Thu, Aug 18, 2005 at 11:03:45PM -0700, Howard Chu wrote:
If the 2.6 kernel makes this programming model unreasonably slow,
then quite simply this kernel is not viable as a database platform.
Pretty much everyone else manages to make it work.
-
To unsubscribe from this list: send the line
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
> in struct net_device_stats all members are defined as unsgined
> long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in
On Sun, Aug 14, 2005 at 09:47:15AM +0100, Christoph Hellwig wrote:
> Looks like people never learn. We had horrible problems with devfs
> because it decided to overload existing name fields, but the udev
> brigade does the same idiocy again..
It's not too late to fix this. We can add a new
On Mon, Aug 15, 2005 at 09:42:37AM -0400, Stephen Frost wrote:
> I also agree and am rather disappointed by this news.
> Unfortunately, I've already bought an A8N-SLI.
If you can send it back citing the driver issues as the reason.
Linux sales are probably a tiny blip on the radar for them so I
On Wed, Aug 17, 2005 at 10:45:48PM +0200, Jesper Juhl wrote:
> It seems slightly odd to me that XFS support should be in a separate
> submenu, when all the other filesystems are not using submenus but
> are directly selectable from the Filesystems menu.
XFS also has an out-of-tree version.
On Wed, Aug 17, 2005 at 10:45:48PM +0200, Jesper Juhl wrote:
It seems slightly odd to me that XFS support should be in a separate
submenu, when all the other filesystems are not using submenus but
are directly selectable from the Filesystems menu.
XFS also has an out-of-tree version. Making
On Mon, Aug 15, 2005 at 09:42:37AM -0400, Stephen Frost wrote:
I also agree and am rather disappointed by this news.
Unfortunately, I've already bought an A8N-SLI.
If you can send it back citing the driver issues as the reason.
Linux sales are probably a tiny blip on the radar for them so I
On Sun, Aug 14, 2005 at 09:47:15AM +0100, Christoph Hellwig wrote:
Looks like people never learn. We had horrible problems with devfs
because it decided to overload existing name fields, but the udev
brigade does the same idiocy again..
It's not too late to fix this. We can add a new field
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
in struct net_device_stats all members are defined as unsgined
long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspace
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
> Hmm... did I mention libsmbios? :-)
> http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more forthcoming with documentation.
> SMI support is not yet
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote:
> I'm worried that it might be more of a mess in userspace than it
> could be if done properly in the kernel.
I would rather if it's gonna be a mess it's, then we put that mess in
userspace rather than in the kernel.
> Hardware
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
> Why can't you just implement the system management actions in the
> kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of userspace support for this driver
but that still doesn't
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
Why can't you just implement the system management actions in the
kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of userspace support for this driver
but that still doesn't
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote:
I'm worried that it might be more of a mess in userspace than it
could be if done properly in the kernel.
I would rather if it's gonna be a mess it's, then we put that mess in
userspace rather than in the kernel.
Hardware drivers,
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
Hmm... did I mention libsmbios? :-)
http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more forthcoming with documentation.
SMI support is not yet
On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote:
> It is used for /class/misc/$name/dev
Ick. I would almost suggest we change that were it not too late. I
think keeping the decription is useful and desirable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote:
It is used for /class/misc/$name/dev
Ick. I would almost suggest we change that were it not too late. I
think keeping the decription is useful and desirable.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Fri, Jul 29, 2005 at 07:31:20AM +0400, Andrey Borzenkov wrote:
> Mandrake always mounted USB sticks with sync option; it was
> effectively noop except for a patch that implemented limited dsync
> semantic.
fwiw; various people have reported using flash block devices with
'sync' ruins them as
On Fri, Jul 29, 2005 at 07:31:20AM +0400, Andrey Borzenkov wrote:
Mandrake always mounted USB sticks with sync option; it was
effectively noop except for a patch that implemented limited dsync
semantic.
fwiw; various people have reported using flash block devices with
'sync' ruins them as
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
> In both cases, what used to be a proper offset in one fd can be
> complete bogus for another one.
Exactly.
Knowing the position within a directory is of questionable value and
trying to implement any reliable semantics for lseek is
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
In both cases, what used to be a proper offset in one fd can be
complete bogus for another one.
Exactly.
Knowing the position within a directory is of questionable value and
trying to implement any reliable semantics for lseek is
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
> To my understanding, you can lseek to any "proper" offset inside a
> directory. Proper means that the offset marks the beginning of a
> new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
To my understanding, you can lseek to any proper offset inside a
directory. Proper means that the offset marks the beginning of a
new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote:
> >So you can seek to m*+ to access an offset into
> >something at depth m?
> >
>
> Yes.
Hos does that work if offset >= m?
> I disagree. Where is the information value of i_size if we always
> could return 0?
Directories clearly
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote:
> Since these "arranged" values are also used as the offsets in the
> return dirent IMO it is quite clean.
So the size you want to reflect is n* i take it? Where
in this case n is 20?
So you can seek to m*+ to access an offset into
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote:
> I'm using the i_size of directories in my patches. When reading
> from a union directory, I'm using the i_size to seek to the right
> offset in the union stack.
Ick. That'a a bit of a hack.
> Therefore I need values of
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote:
I'm using the i_size of directories in my patches. When reading
from a union directory, I'm using the i_size to seek to the right
offset in the union stack.
Ick. That'a a bit of a hack.
Therefore I need values of dirent-d_off
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote:
Since these arranged values are also used as the offsets in the
return dirent IMO it is quite clean.
So the size you want to reflect is n*stack-depth i take it? Where
in this case n is 20?
So you can seek to m*stack-depth+offset to
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote:
So you can seek to m*stack-depth+offset to access an offset into
something at depth m?
Yes.
Hos does that work if offset = m?
I disagree. Where is the information value of i_size if we always
could return 0?
Directories
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote:
> Because the hardware interfaces on those systems and the Dell
> systems management software that access the interfaces are
> proprietary, I can't provide specifications for the interfaces or
> source code for the software.
So you
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote:
Because the hardware interfaces on those systems and the Dell
systems management software that access the interfaces are
proprietary, I can't provide specifications for the interfaces or
source code for the software.
So you want
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote:
> I really think you should update the "simple_xxx()" functions
> instead, and thus make this happen for _any_ filesystem that uses
> the simple fs helper functions.
Why bother at all?
I don't see why zero sizes are a problem.
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote:
> So, the 13-year-old design advice will continue to apply to
> 13-year-old systems, but newer systems with C3 and HPET
> should be using them.
Last I looked HPET isn't everywhere yet (absent from nforce4
mainboards for example, but
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote:
So, the 13-year-old design advice will continue to apply to
13-year-old systems, but newer systems with C3 and HPET
should be using them.
Last I looked HPET isn't everywhere yet (absent from nforce4
mainboards for example, but that
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote:
I really think you should update the simple_xxx() functions
instead, and thus make this happen for _any_ filesystem that uses
the simple fs helper functions.
Why bother at all?
I don't see why zero sizes are a problem. We've
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
> AFAIK John simply wants to change jiffies to count in nanoseconds
> since bootup and then call it "clock_monotonic".
Clocks and counter drift so calling it seconds would be
misleading. It would really only be good for
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
AFAIK John simply wants to change jiffies to count in nanoseconds
since bootup and then call it clock_monotonic.
Clocks and counter drift so calling it prefixseconds would be
misleading. It would really only be good for
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
> windows xp base rate is 100Hz... but multimedia apps can ask for
> almost any rate they want (depends on the hw capabilities). i
> recall seeing rates >1200Hz when you launch some of the media player
> apps -- sorry i forget the
On Wed, Jul 13, 2005 at 05:24:41PM -0400, Lee Revell wrote:
> Does anyone object to setting HZ at boot? I suspect nothing else
> will make everyone happy.
Does it bloat the code or slow things measurably?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
> Len Brown, a year ago: "The bottom line number to laptop users is
> battery lifetime. Just today somebody complained to me that Windows
> gets twice the battery life that Linux does."
It seems the motivation for lower HZ is
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
Len Brown, a year ago: The bottom line number to laptop users is
battery lifetime. Just today somebody complained to me that Windows
gets twice the battery life that Linux does.
It seems the motivation for lower HZ is really:
On Wed, Jul 13, 2005 at 05:24:41PM -0400, Lee Revell wrote:
Does anyone object to setting HZ at boot? I suspect nothing else
will make everyone happy.
Does it bloat the code or slow things measurably?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
windows xp base rate is 100Hz... but multimedia apps can ask for
almost any rate they want (depends on the hw capabilities). i
recall seeing rates 1200Hz when you launch some of the media player
apps -- sorry i forget the exact
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote:
> The real answer here is for the tickless patches to cleaned up to
> the point where they can be merged, and then we won't waste battery
> power entering the timer interrupt in the first place. :-)
Whilst conceptually this is a
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote:
The real answer here is for the tickless patches to cleaned up to
the point where they can be merged, and then we won't waste battery
power entering the timer interrupt in the first place. :-)
Whilst conceptually this is a nice
On Sat, Jul 09, 2005 at 04:41:16PM +0200, Ingo Molnar wrote:
> this patch pushes the creation of a rare signal frame (SIGBUS or
> SIGSEGV) into a separate function, thus saving stackspace in the
> main do_page_fault() stackframe. The effect is 132 bytes less of
> stack used by the typical
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote:
> BTW, Christoph Lameter, if you're seeing this, your mail is bouncing...
my bad, i typoed it when i first send the original email
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote:
> it's a config option. Some distros ship 100 already, others 1000,
> again others will do 250.
Who does anything other than 1000 for a 2.6.x kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote:
it's a config option. Some distros ship 100 already, others 1000,
again others will do 250.
Who does anything other than 1000 for a 2.6.x kernel?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote:
BTW, Christoph Lameter, if you're seeing this, your mail is bouncing...
my bad, i typoed it when i first send the original email
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Sat, Jul 09, 2005 at 04:41:16PM +0200, Ingo Molnar wrote:
this patch pushes the creation of a rare signal frame (SIGBUS or
SIGSEGV) into a separate function, thus saving stackspace in the
main do_page_fault() stackframe. The effect is 132 bytes less of
stack used by the typical
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote:
> I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I
> can confirm more explicitly if really need be. 48s -> 45.5s elapsed.
That's a huge difference (5%) --- what hardware is that on?
-
To unsubscribe from this
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote:
> > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> ^^
> It's been over two weeks and nobody has complained about anything.
Two weeks isn't that long IMO (I only just noticed myself).
>
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> [PATCH] i386: Selectable Frequency of the Timer Interrupt
[...]
> +choice
> + prompt "Timer frequency"
> + default HZ_250
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Changing
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
[PATCH] i386: Selectable Frequency of the Timer Interrupt
[...]
+choice
+ prompt Timer frequency
+ default HZ_250
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Changing the
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote:
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
^^
It's been over two weeks and nobody has complained about anything.
Two weeks isn't that long IMO (I only just noticed myself).
Because
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote:
I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I
can confirm more explicitly if really need be. 48s - 45.5s elapsed.
That's a huge difference (5%) --- what hardware is that on?
-
To unsubscribe from this list:
On Tue, Jul 05, 2005 at 07:13:34PM -0500, Doug Warzecha wrote:
> This patch adds the Dell Systems Management Base driver.
You keep posting this driver without explaining/showing how it's used.
Could you perhaps give some more details here please?
-
To unsubscribe from this list: send the line
On Tue, Jul 05, 2005 at 07:13:34PM -0500, Doug Warzecha wrote:
This patch adds the Dell Systems Management Base driver.
You keep posting this driver without explaining/showing how it's used.
Could you perhaps give some more details here please?
-
To unsubscribe from this list: send the line
101 - 200 of 363 matches
Mail list logo
