On Wed, 2014-03-05 at 16:11 -0500, Jason Cooper wrote:
> > In other words, if there are 4096 bits of "unknownness" in X to start
> > with, and I can get those same 4096 bits of "unknownness" back by
> > unmixing X' and Y, then there must still be 4096 bits of "unknownness"
> > in X'. If X' is 4096
On Wed, 2014-03-05 at 16:11 -0500, Jason Cooper wrote:
In other words, if there are 4096 bits of unknownness in X to start
with, and I can get those same 4096 bits of unknownness back by
unmixing X' and Y, then there must still be 4096 bits of unknownness
in X'. If X' is 4096 bits long,
On Tue, 2014-03-04 at 11:59 -0800, Kees Cook wrote:
> On Tue, Mar 4, 2014 at 11:53 AM, Jason Cooper wrote:
> > On Tue, Mar 04, 2014 at 11:01:49AM -0800, Kees Cook wrote:
> >> On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper wrote:
> >> > Kees, Ted,
> >> >
> >> > On Mon, Mar 03, 2014 at 03:51:48PM
On Tue, 2014-03-04 at 11:59 -0800, Kees Cook wrote:
On Tue, Mar 4, 2014 at 11:53 AM, Jason Cooper ja...@lakedaemon.net wrote:
On Tue, Mar 04, 2014 at 11:01:49AM -0800, Kees Cook wrote:
On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper ja...@lakedaemon.net wrote:
Kees, Ted,
On Mon, Mar 03,
On Mon, 2012-08-13 at 10:26 -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin"
>
> When we write entropy into a non-empty pool, we currently don't
> account at all for the fact that we will probabilistically overwrite
> some of the entropy in that pool.
Technically, no, nothing is
On Mon, 2012-08-13 at 10:26 -0700, H. Peter Anvin wrote:
From: H. Peter Anvin h...@linux.intel.com
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool.
Technically, no, nothing
On Fri, 2012-07-20 at 13:15 -0700, Tony Luck wrote:
> Send the entire DMI (SMBIOS) table to the /dev/random driver to
> help seed its pools.
>
> Signed-off-by: Tony Luck
> ---
>
> This looks a useful addition to your /dev/random series. There are
> lots of platform specific goodies in this
On Fri, 2012-07-20 at 13:15 -0700, Tony Luck wrote:
Send the entire DMI (SMBIOS) table to the /dev/random driver to
help seed its pools.
Signed-off-by: Tony Luck tony.l...@intel.com
---
This looks a useful addition to your /dev/random series. There are
lots of platform specific goodies
On Fri, 2012-07-06 at 12:52 -0400, Theodore Ts'o wrote:
> On Fri, Jul 06, 2012 at 09:24:00AM -0700, Linus Torvalds wrote:
> > On Fri, Jul 6, 2012 at 6:01 AM, Theodore Ts'o wrote:
> > > What in the world is "fast count"? I've grepped for it,
> > > and I can't find it.
> >
> > It's your own
On Fri, 2012-07-06 at 12:52 -0400, Theodore Ts'o wrote:
On Fri, Jul 06, 2012 at 09:24:00AM -0700, Linus Torvalds wrote:
On Fri, Jul 6, 2012 at 6:01 AM, Theodore Ts'o ty...@mit.edu wrote:
What in the world is fast count? I've grepped for it,
and I can't find it.
It's your own
On Mon, 2008-02-25 at 18:53 +0100, Thomas Petazzoni wrote:
> Le Mon, 25 Feb 2008 09:03:12 -0800,
> Matt Mackall <[EMAIL PROTECTED]> a écrit :
>
> > > > This is not quite what Peter and I were thinking of, I think.
> > > > It's not at all generic. H
On Mon, 2008-02-25 at 09:29 +0100, Thomas Petazzoni wrote:
> Le Sat, 23 Feb 2008 10:43:37 +0800,
> Matt Mackall <[EMAIL PROTECTED]> a écrit :
>
> > This is not quite what Peter and I were thinking of, I think. It's not
> > at all generic. How about a section
On Mon, 2008-02-25 at 09:29 +0100, Thomas Petazzoni wrote:
Le Sat, 23 Feb 2008 10:43:37 +0800,
Matt Mackall [EMAIL PROTECTED] a écrit :
This is not quite what Peter and I were thinking of, I think. It's not
at all generic. How about a section that simply contains a set of
function
On Mon, 2008-02-25 at 18:53 +0100, Thomas Petazzoni wrote:
Le Mon, 25 Feb 2008 09:03:12 -0800,
Matt Mackall [EMAIL PROTECTED] a écrit :
This is not quite what Peter and I were thinking of, I think.
It's not at all generic. How about a section that simply contains
a set of function
On Sat, 2008-02-23 at 00:06 -0800, Andrew Morton wrote:
> On Wed, 20 Feb 2008 14:57:43 +0100 "Hans Rosenfeld" <[EMAIL PROTECTED]> wrote:
>
> > The current code for /proc/pid/pagemap does not work with huge pages (on
> > x86). The code will make no difference between a normal pmd and a huge
> >
On Sat, 2008-02-23 at 00:06 -0800, Andrew Morton wrote:
On Wed, 20 Feb 2008 14:57:43 +0100 Hans Rosenfeld [EMAIL PROTECTED] wrote:
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd,
On Fri, 2008-02-15 at 12:00 +0100, Thomas Petazzoni wrote:
> Hi,
>
> Le Mon, 11 Feb 2008 16:54:30 -0800,
> "H. Peter Anvin" <[EMAIL PROTECTED]> a écrit :
>
> > b) would be my first choice, and yes, it would be a good thing to
> > have a generalized mechanism for this. For the registrant, it's
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
The current code for /proc/pid/pagemap does not work with huge pages (on
x86). The code will make no difference between a normal pmd and a huge
page pmd, trying to parse the contents of the huge page as
On Fri, 2008-02-15 at 12:00 +0100, Thomas Petazzoni wrote:
Hi,
Le Mon, 11 Feb 2008 16:54:30 -0800,
H. Peter Anvin [EMAIL PROTECTED] a écrit :
b) would be my first choice, and yes, it would be a good thing to
have a generalized mechanism for this. For the registrant, it's
pretty
On Thu, 2008-02-21 at 10:53 +0100, Ingo Molnar wrote:
> * Huang, Ying <[EMAIL PROTECTED]> wrote:
>
> > > > -int __initdata early_ioremap_debug;
> > > > +int __initbss early_ioremap_debug;
> > >
> > > will we get some sort of build error if we accidentally do:
> > >
> > >int __initbss
On Thu, 2008-02-21 at 10:53 +0100, Ingo Molnar wrote:
* Huang, Ying [EMAIL PROTECTED] wrote:
-int __initdata early_ioremap_debug;
+int __initbss early_ioremap_debug;
will we get some sort of build error if we accidentally do:
int __initbss early_ioremap_debug = 1;
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote:
> On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
> > On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
> > > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
> > > 2.6.25
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
> On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
> > In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
> > 2.6.25-rc1, the unified ioremap.o is 20.8k.
>
> Just an observation - 17 comm
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
2.6.25-rc1, the unified ioremap.o is 20.8k.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 2008-02-15 at 19:04 +0100, Andi Kleen wrote:
> > do when it does". There's very little point in having this sort of code
> > in a mass-market camera, phone, DVR, TV, etc. (of which there are
>
> Do any of them run with a x86 CPU?
Yes. The last PVR I worked on was just such a device, as
On Fri, 2008-02-15 at 13:00 +0100, Andi Kleen wrote:
> Matt Mackall <[EMAIL PROTECTED]> writes:
> >
> > I bet there's some doublefault-handling code hiding somewhere. It's not
> > the sort of thing it'd make sense to take out of the architecture.
>
> The big que
On Fri, 2008-02-15 at 19:04 +0100, Andi Kleen wrote:
do when it does. There's very little point in having this sort of code
in a mass-market camera, phone, DVR, TV, etc. (of which there are
Do any of them run with a x86 CPU?
Yes. The last PVR I worked on was just such a device, as was the
On Fri, 2008-02-15 at 13:00 +0100, Andi Kleen wrote:
Matt Mackall [EMAIL PROTECTED] writes:
I bet there's some doublefault-handling code hiding somewhere. It's not
the sort of thing it'd make sense to take out of the architecture.
The big question is if it makes sense taking out
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
2.6.25-rc1, the unified ioremap.o is 20.8k.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
2.6.25-rc1, the unified ioremap.o is 20.8k.
Just an observation - 17 commits touches said file after
On Fri, 2008-02-15 at 15:21 -0600, Matt Mackall wrote:
On Fri, 2008-02-15 at 21:32 +0100, Sam Ravnborg wrote:
On Fri, Feb 15, 2008 at 02:25:54PM -0600, Matt Mackall wrote:
In 2.6.24 defconfig, my build stats show ioremap_32.o was 1.8k. In
2.6.25-rc1, the unified ioremap.o is 20.8k
On Wed, 2008-02-13 at 23:30 +0200, Adrian Bunk wrote:
> This patch makes the needlessly global swap_pte_to_pagemap_entry()
> static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Thanks.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
--
Mathematics is the supre
On Wed, 2008-02-13 at 23:30 +0200, Adrian Bunk wrote:
This patch makes the needlessly global swap_pte_to_pagemap_entry()
static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Thanks.
Signed-off-by: Matt Mackall [EMAIL PROTECTED]
--
Mathematics is the supreme nostalgia of our time
t;textdata bss dec hex filename
> -7984 -2348 0 -10332 -285c vmlinux
>
> The new option appears in "Processor type and features", only when
> CONFIG_EMBEDDED is defined.
>
> This patch is part of the Linux Tiny project, and is bas
On Tue, 2008-02-12 at 15:00 +0100, Thomas Petazzoni wrote:
> Hi Sam,
>
> Le Tue, 12 Feb 2008 14:04:28 +0100,
> Sam Ravnborg <[EMAIL PROTECTED]> a écrit :
>
> > We already have this in arch/x86/Kconfig.debug:
>
> Oops, my usual "find . -name Kconfig" missed it. Thanks for pointing it
> out!
0 -10332 -285c vmlinux
The new option appears in Processor type and features, only when
CONFIG_EMBEDDED is defined.
This patch is part of the Linux Tiny project, and is based on previous
work done by Matt Mackall [EMAIL PROTECTED].
Signed-off-by: Thomas Petazzoni [EMAIL PROTECTED
On Tue, 2008-02-12 at 15:00 +0100, Thomas Petazzoni wrote:
Hi Sam,
Le Tue, 12 Feb 2008 14:04:28 +0100,
Sam Ravnborg [EMAIL PROTECTED] a écrit :
We already have this in arch/x86/Kconfig.debug:
Oops, my usual find . -name Kconfig missed it. Thanks for pointing it
out!
The fact that
On Mon, 2008-02-11 at 16:54 -0800, H. Peter Anvin wrote:
> Matt Mackall wrote:
> > On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote:
> >> Matt Mackall wrote:
> >>> Best would be to have no ifdefs and do it all with linker magic, of
> >>> course
On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote:
> Matt Mackall wrote:
> >
> > Best would be to have no ifdefs and do it all with linker magic, of
> > course. But that's trickier.
> >
>
> I concur with this, definitely.
Ok, so let's come up with a p
On Mon, 2008-02-11 at 23:42 +0100, Michael Opdenacker wrote:
> /* Specific CPU type init functions */
> -int intel_cpu_init(void);
> -int amd_init_cpu(void);
> -int cyrix_init_cpu(void);
> -int nsc_init_cpu(void);
> -int centaur_init_cpu(void);
> -int transmeta_init_cpu(void);
> -int
On Tue, 2008-02-12 at 00:32 +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> UML has some header magic that expects a non-inline __kmalloc() function to be
> available. Fixes the following link time errors:
>
> arch/um/drivers/built-in.o: In function `kmalloc':
>
On Mon, 2008-02-11 at 17:58 +0100, Thomas Petazzoni wrote:
> Hi,
>
> The enclosed patch allows to remove the DMI scanning code when
> CONFIG_EMBEDDED is defined. It's basically the dma_blacklist patch of
> Linux-Tiny ported to 2.6.25-rc1, with the required modifications. It
> allows to remove
On Mon, 2008-02-11 at 18:08 +0900, Joonwoo Park wrote:
> This patch intorduces cmdline netconsole configs to register to
> configfs
> with dynamic netconsole. Satyam Sharma who designed shiny dynamic
> reconfiguration for netconsole, mentioned about this issue already.
>
On Mon, 2008-02-11 at 23:42 +0100, Michael Opdenacker wrote:
/* Specific CPU type init functions */
-int intel_cpu_init(void);
-int amd_init_cpu(void);
-int cyrix_init_cpu(void);
-int nsc_init_cpu(void);
-int centaur_init_cpu(void);
-int transmeta_init_cpu(void);
-int
On Mon, 2008-02-11 at 17:58 +0100, Thomas Petazzoni wrote:
Hi,
The enclosed patch allows to remove the DMI scanning code when
CONFIG_EMBEDDED is defined. It's basically the dma_blacklist patch of
Linux-Tiny ported to 2.6.25-rc1, with the required modifications. It
allows to remove ~10k
On Mon, 2008-02-11 at 18:08 +0900, Joonwoo Park wrote:
This patch intorduces cmdline netconsole configs to register to
configfs
with dynamic netconsole. Satyam Sharma who designed shiny dynamic
reconfiguration for netconsole, mentioned about this issue already.
On Tue, 2008-02-12 at 00:32 +0200, Pekka J Enberg wrote:
From: Pekka Enberg [EMAIL PROTECTED]
UML has some header magic that expects a non-inline __kmalloc() function to be
available. Fixes the following link time errors:
arch/um/drivers/built-in.o: In function `kmalloc':
On Mon, 2008-02-11 at 16:54 -0800, H. Peter Anvin wrote:
Matt Mackall wrote:
On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote:
Matt Mackall wrote:
Best would be to have no ifdefs and do it all with linker magic, of
course. But that's trickier.
I concur with this, definitely
On Mon, 2008-02-11 at 15:01 -0800, H. Peter Anvin wrote:
Matt Mackall wrote:
Best would be to have no ifdefs and do it all with linker magic, of
course. But that's trickier.
I concur with this, definitely.
Ok, so let's come up with a plan. We can:
a) use weak symbols, ala
On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote:
> This patch against x86/mm tries to revive an original patch
> from Matt Mackall which didn't get merged at that time. It makes
> it possible to disable support code for some processors. This can
> be useful to support on
On Fri, 2008-02-08 at 14:05 -0800, Andrew Morton wrote:
> On Fri, 08 Feb 2008 15:41:42 -0600
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Fix compile error on nommu for is_swap_pte
> >
> > Does it ever make sense to ask "is this pte a swap entry?&quo
On Fri, 2008-02-08 at 16:25 -0500, Mike Frysinger wrote:
> On Friday 08 February 2008, Matt Mackall wrote:
> > On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
> > > With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was
> > > moved into view of
On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
> With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was moved
> into view of both MMU and !MMU, but uses functions only provided by MMU.
> Here we stub out the function for !MMU ports.
I'm not sure if this is right compared
On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was moved
into view of both MMU and !MMU, but uses functions only provided by MMU.
Here we stub out the function for !MMU ports.
I'm not sure if this is right compared to
On Fri, 2008-02-08 at 16:25 -0500, Mike Frysinger wrote:
On Friday 08 February 2008, Matt Mackall wrote:
On Fri, 2008-02-08 at 15:02 -0500, Mike Frysinger wrote:
With commit 698dd4ba6b12e34e1e432c944c01478c0b2cd773, swap_pte() was
moved into view of both MMU and !MMU, but uses functions
On Fri, 2008-02-08 at 23:47 +0100, Michael Opdenacker wrote:
This patch against x86/mm tries to revive an original patch
from Matt Mackall which didn't get merged at that time. It makes
it possible to disable support code for some processors. This can
be useful to support only the exact
8: error:
> implicit declaration of function 'pte_present'
> make[2]: *** [mm/vmscan.o] Error 1
This suggests that no one's tried to compile -mm on Blackfin since
before September, I think.
Is there somewhere more appropriate to move it? I can't find one.
Failing that, we can wrap it in
'
make[2]: *** [mm/vmscan.o] Error 1
This suggests that no one's tried to compile -mm on Blackfin since
before September, I think.
Is there somewhere more appropriate to move it? I can't find one.
Failing that, we can wrap it in CONFIG_MMU, I suppose.
Signed-off-by: Matt Mackall [EMAIL PROTECTED
> err, Matt?
random: revert braindamage that snuck into checkpatch cleanup
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
diff -r 50a6e531a9f2 drivers/char/random.c
--- a/drivers/char/random.c Mon Feb 04 20:23:02 2008 -0600
+++ b/drivers/char/random.c Mon Feb 04 20:28:08 2008 -
On Mon, 2008-02-04 at 16:24 -0800, Linus Torvalds wrote:
>
> On Mon, 4 Feb 2008, Matt Mackall wrote:
> >
> > But ATAoE is boring because it's not IP. Which means no routing,
> > firewalls, tunnels, congestion control, etc.
>
> The thing is, that's often an advan
On Mon, 2008-02-04 at 22:43 +, Alan Cox wrote:
> > better. So for example, I personally suspect that ATA-over-ethernet is way
> > better than some crazy SCSI-over-TCP crap, but I'm biased for simple and
> > low-level, and against those crazy SCSI people to begin with.
>
> Current ATAoE
On Mon, 2008-02-04 at 22:43 +, Alan Cox wrote:
better. So for example, I personally suspect that ATA-over-ethernet is way
better than some crazy SCSI-over-TCP crap, but I'm biased for simple and
low-level, and against those crazy SCSI people to begin with.
Current ATAoE isn't. It
On Mon, 2008-02-04 at 16:24 -0800, Linus Torvalds wrote:
On Mon, 4 Feb 2008, Matt Mackall wrote:
But ATAoE is boring because it's not IP. Which means no routing,
firewalls, tunnels, congestion control, etc.
The thing is, that's often an advantage. Not just for performance.
NBD
into checkpatch cleanup
Signed-off-by: Matt Mackall [EMAIL PROTECTED]
diff -r 50a6e531a9f2 drivers/char/random.c
--- a/drivers/char/random.c Mon Feb 04 20:23:02 2008 -0600
+++ b/drivers/char/random.c Mon Feb 04 20:28:08 2008 -0600
@@ -1306,7 +1306,7 @@
* Rotation is separate from addition
On Wed, 2008-01-30 at 22:02 +0200, Adrian Bunk wrote:
> This patch removes the no longer used EXPORT_SYMBOL(add_disk_randomness).
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
> ---
> f1a195a30248eae541ba006633a
On Tue, 2008-01-29 at 16:14 +0200, Heikki Orsila wrote:
> > > Imo,
> > > "same exact C compiler" is just bad language, because C compilers are
> > > always "exact". "exactly same C compiler" would do.
> >
> > No, "exactly same C compiler" doesn't parse well in English.
>
> "Same exact C
On Wed, 2008-01-30 at 18:28 +0100, Peter Zijlstra wrote:
> Subject: mm: MADV_WILLNEED implementation for anonymous memory
>
> Implement MADV_WILLNEED for anonymous pages by walking the page tables and
> starting asynchonous swap cache reads for all encountered swap pages.
>
> Doing so required
On Wed, 2008-01-30 at 18:28 +0100, Peter Zijlstra wrote:
Subject: mm: MADV_WILLNEED implementation for anonymous memory
Implement MADV_WILLNEED for anonymous pages by walking the page tables and
starting asynchonous swap cache reads for all encountered swap pages.
Doing so required a
On Tue, 2008-01-29 at 16:14 +0200, Heikki Orsila wrote:
Imo,
same exact C compiler is just bad language, because C compilers are
always exact. exactly same C compiler would do.
No, exactly same C compiler doesn't parse well in English.
Same exact C compiler does not mean what
On Wed, 2008-01-30 at 22:02 +0200, Adrian Bunk wrote:
This patch removes the no longer used EXPORT_SYMBOL(add_disk_randomness).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Matt Mackall [EMAIL PROTECTED]
---
f1a195a30248eae541ba006633aa70385d1eb785
diff --git a/drivers/char
On Wed, 2008-01-23 at 16:28 -0800, Jeremy Fitzhardinge wrote:
> When changing a kernel page from RO->RW, it's OK to leave stale TLB
> entries around, since doing a global flush is expensive and they pose
> no security problem. They can, however, generate a spurious fault,
> which we should catch
On Thu, 2008-01-24 at 12:36 +1100, Nick Piggin wrote:
> On Thursday 24 January 2008 04:05, Linus Torvalds wrote:
> > On Wed, 23 Jan 2008, Anton Salikhmetov wrote:
> > > +
> > > + if (pte_dirty(*pte) && pte_write(*pte)) {
> >
> > Not correct.
> >
> > You still need to check "pte_present()"
On Wed, 2008-01-23 at 09:53 +0100, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > that would probably be the case if it's multiple sockets - but for
> > multiple cores exactly the opposite is true: the sooner _both_ cores
> > finish processing, the deeper power use the CPU
On Wed, 2008-01-23 at 09:53 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
that would probably be the case if it's multiple sockets - but for
multiple cores exactly the opposite is true: the sooner _both_ cores
finish processing, the deeper power use the CPU can reach.
On Tue, 2008-01-22 at 22:59 +, Hugh Dickins wrote:
> On Tue, 22 Jan 2008, James Bottomley wrote:
> >
> > libsas looks to be OK because it specifically kmallocs a 512 byte buffer
> > which should (for off slab data) be 512 byte aligned.
>
> I don't remember the various SLAB and SLOB and SLUB
On Tue, 2008-01-22 at 19:58 +0100, Sam Ravnborg wrote:
> On Tue, Jan 22, 2008 at 10:37:19AM -0600, Matt Mackall wrote:
> >
> > On Tue, 2008-01-22 at 15:39 +0100, Ingo Molnar wrote:
> > > threadinfo-ool.patch: doesnt this break the scheduler?
> >
> > It
On Tue, 2008-01-22 at 17:05 +0100, Ingo Molnar wrote:
> * S.Çağlar Onur <[EMAIL PROTECTED]> wrote:
>
> > > My theory is that for whatever reason we get "repeat" IPIs: multiple
> > > reschedule IPIs although the other CPU only initiated one.
> >
> > Ok, please see
On Tue, 2008-01-22 at 15:39 +0100, Ingo Molnar wrote:
> threadinfo-ool.patch: doesnt this break the scheduler?
It didn't when I wrote it, 3+ years ago. But I'm sure it needs to be
revisited.
> tiny-cflags.patch: obsolete? Isnt CFLAGS already extendable? Question to
> Sam i guess.
Yup.
--
On Tue, 2008-01-22 at 15:39 +0100, Ingo Molnar wrote:
threadinfo-ool.patch: doesnt this break the scheduler?
It didn't when I wrote it, 3+ years ago. But I'm sure it needs to be
revisited.
tiny-cflags.patch: obsolete? Isnt CFLAGS already extendable? Question to
Sam i guess.
Yup.
--
On Tue, 2008-01-22 at 17:05 +0100, Ingo Molnar wrote:
* S.Çağlar Onur [EMAIL PROTECTED] wrote:
My theory is that for whatever reason we get repeat IPIs: multiple
reschedule IPIs although the other CPU only initiated one.
Ok, please see
On Tue, 2008-01-22 at 19:58 +0100, Sam Ravnborg wrote:
On Tue, Jan 22, 2008 at 10:37:19AM -0600, Matt Mackall wrote:
On Tue, 2008-01-22 at 15:39 +0100, Ingo Molnar wrote:
threadinfo-ool.patch: doesnt this break the scheduler?
It didn't when I wrote it, 3+ years ago. But I'm sure
On Tue, 2008-01-22 at 22:59 +, Hugh Dickins wrote:
On Tue, 22 Jan 2008, James Bottomley wrote:
libsas looks to be OK because it specifically kmallocs a 512 byte buffer
which should (for off slab data) be 512 byte aligned.
I don't remember the various SLAB and SLOB and SLUB rules
On Tue, 2008-01-22 at 10:00 +0900, Tejun Heo wrote:
> Matt Mackall wrote:
> > I suppose. I still find this approach less than ideal, especially
> > putting something potentially large on the stack. The dangers are
> > perhaps worse than a malloc, really.
>
&g
On Sat, 2008-01-19 at 07:58 +0900, Tejun Heo wrote:
> Matt Mackall wrote:
> > On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote:
> >> And mprintk the following.
> >>
> >> code:
> >> DEFINE_MPRINTK(mp, 2 * 80);
> >>
>
On Mon, 2008-01-21 at 13:18 -0500, Jeff Dike wrote:
> Add async notification support to /dev/random.
This conflicts just about everywhere with my latest code, but I'll fix
that up.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line
On Mon, 2008-01-21 at 13:18 -0500, Jeff Dike wrote:
Add async notification support to /dev/random.
This conflicts just about everywhere with my latest code, but I'll fix
that up.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line unsubscribe
On Sat, 2008-01-19 at 07:58 +0900, Tejun Heo wrote:
Matt Mackall wrote:
On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote:
And mprintk the following.
code:
DEFINE_MPRINTK(mp, 2 * 80);
mprintk_set_header(mp, KERN_INFO ata%u.%2u: , 1, 0);
mprintk_push(mp, ATA %d, 7
On Tue, 2008-01-22 at 10:00 +0900, Tejun Heo wrote:
Matt Mackall wrote:
I suppose. I still find this approach less than ideal, especially
putting something potentially large on the stack. The dangers are
perhaps worse than a malloc, really.
I pondered on this a bit but the thing is we
On Sun, 2008-01-20 at 12:24 -0600, Robert Hancock wrote:
> David Newall wrote:
> > Andi Kleen wrote:
> >>> Isn't it the case that an idle machine will use
> >>> less power when throttled than when not?
> >>>
> >> No that is not the case (not even on old CPUs)
> >>
> > Then why would it
On Sat, 2008-01-19 at 22:59 -0600, Rob Landley wrote:
> On Friday 18 January 2008 11:10:19 Matt Mackall wrote:
> > > * Disable support for readahead, page writeback, pdflush and swap
> > > when we have no storage at all (typically booting from an
> > >
On Sat, 2008-01-19 at 22:59 -0600, Rob Landley wrote:
On Friday 18 January 2008 11:10:19 Matt Mackall wrote:
* Disable support for readahead, page writeback, pdflush and swap
when we have no storage at all (typically booting from an
initramfs). This corresponds to 69 KB
On Sun, 2008-01-20 at 12:24 -0600, Robert Hancock wrote:
David Newall wrote:
Andi Kleen wrote:
Isn't it the case that an idle machine will use
less power when throttled than when not?
No that is not the case (not even on old CPUs)
Then why would it run cooler? What
On Sat, 2008-01-19 at 11:22 +0100, Miklos Szeredi wrote:
> > Reminds me, I've got a patch here for addressing that problem with loop
> > mounts:
> >
> > Writes to loop should update the mtime of the underlying file.
> >
> > Signed-off-by: Matt Mackall &
On Sat, 2008-01-19 at 11:22 +0100, Miklos Szeredi wrote:
Reminds me, I've got a patch here for addressing that problem with loop
mounts:
Writes to loop should update the mtime of the underlying file.
Signed-off-by: Matt Mackall [EMAIL PROTECTED]
Index: l/drivers/block/loop.c
On Sat, 2008-01-19 at 05:27 +0100, Andi Kleen wrote:
> > So while throttling may be less efficient in terms of watt seconds used
> > to compile something than running at full speed, it is incorrect to say
> > it uses less power. One machine running for an hour throttled to 50%
> > uses less power
On Sat, 2008-01-19 at 02:15 +0100, Andi Kleen wrote:
> On Fri, Jan 18, 2008 at 06:27:57PM -0600, Matt Mackall wrote:
> >
> > On Fri, 2008-01-18 at 22:11 +0100, Andi Kleen wrote:
> > > Chodorenko Michail <[EMAIL PROTECTED]> writes:
> > >
> > > >
unts:
Writes to loop should update the mtime of the underlying file.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: l/drivers/block/loop.c
===
--- l.orig/drivers/block/loop.c 2007-11-05 17:50:07.0 -0600
+++ l/dr
On Fri, 2008-01-18 at 22:11 +0100, Andi Kleen wrote:
> Chodorenko Michail <[EMAIL PROTECTED]> writes:
>
> > I have a laptop "Extensa 5220", with the processor Celeron based on 'core'
> > technology.
> > There is ~ / arch/i386/kernel/cpu/cpufreq/p4-clockmod.c in the kernel
> > source code
> > but
On Fri, 2008-01-18 at 22:09 +0100, Ingo Molnar wrote:
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > Sounds fine! Don't hesitate to let us know about the lower-hanging
> > > fruit you're thinking about. Here are the main things I have so far:
> > >
1 - 100 of 1967 matches
Mail list logo
