On Wed, Dec 12, 2007 at 12:48:09PM +0100, Mikael Pettersson wrote:
> IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
> and avoids having to write an uninteresting type name.
How about this, then?
The ->cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B.
The ->cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
list_head fields. This resulted in silent corruption without
CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
the proper bounds to the
The -cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
list_head fields. This resulted in silent corruption without
CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
the proper bounds to the
On Wed, Dec 12, 2007 at 12:48:09PM +0100, Mikael Pettersson wrote:
IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
and avoids having to write an uninteresting type name.
How about this, then?
The -cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B.
On Fri, Nov 30, 2007 at 12:02:32AM +0530, Ciju Rajan K wrote:
> I tested your patch. But that is not solving the problem.
> If the code change to user_shm_lock() is not a good solution, could
> you please suggest a method so that the normal user is able to allocate
> the huge pages, if his
On Fri, Nov 30, 2007 at 12:02:32AM +0530, Ciju Rajan K wrote:
I tested your patch. But that is not solving the problem.
If the code change to user_shm_lock() is not a good solution, could
you please suggest a method so that the normal user is able to allocate
the huge pages, if his gid
Linus Torvalds wrote:
>> IIRC, the present bit is ignored in the magic 4-entry PGD. All entries
>> have to be present.
On Thu, Nov 15, 2007 at 02:42:46PM -0800, H. Peter Anvin wrote:
> This is true, although you could point a PGD to an all-zero page if you
> really wanted to. You have to
Linus Torvalds wrote:
IIRC, the present bit is ignored in the magic 4-entry PGD. All entries
have to be present.
On Thu, Nov 15, 2007 at 02:42:46PM -0800, H. Peter Anvin wrote:
This is true, although you could point a PGD to an all-zero page if you
really wanted to. You have to re-load
On Wed, Nov 14, 2007 at 09:31:41AM -0600, aglitke wrote:
> ... if the user's locked limit (ulimit -l) is set to unlimited, allowed
> (above) is set to 1. In that case, the second part of that if() is
> bypassed, and the function grants permission. Therefore, the easy
> solution is to make sure
On Wed, Nov 14, 2007 at 09:31:41AM -0600, aglitke wrote:
... if the user's locked limit (ulimit -l) is set to unlimited, allowed
(above) is set to 1. In that case, the second part of that if() is
bypassed, and the function grants permission. Therefore, the easy
solution is to make sure your
On Wed, Jul 25, 2007 at 04:39:04PM +0200, Andrea Arcangeli wrote:
> For the kernel stack btw, when alloc_pages(order=1) fails vmalloc
> should be used and 4k stacks can be dropped. Nobody does dma from the
> stack anymore these days IIRC (it doesn't work in all archs anyway).
I have recent code
On Wed, Jul 25, 2007 at 04:39:04PM +0200, Andrea Arcangeli wrote:
For the kernel stack btw, when alloc_pages(order=1) fails vmalloc
should be used and 4k stacks can be dropped. Nobody does dma from the
stack anymore these days IIRC (it doesn't work in all archs anyway).
I have recent code for
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
>> Actually I'd worked on what was called MPSS (Multiple Page Size Support)
>> before I ever started on pgcl. Some large portion of the pgcl proposal
>> as I presented it internally was to reduce the o
On Wed, Jul 18, 2007 at 06:32:22AM -0700, William Lee Irwin III wrote:
Actually I'd worked on what was called MPSS (Multiple Page Size Support)
before I ever started on pgcl. Some large portion of the pgcl proposal
as I presented it internally was to reduce the order of large page
allocations
From: William Lee Irwin III <[EMAIL PROTECTED]>
>> PAE is useful for more than supporting more than 4GB RAM. It supports
>> expanded swapspace and NX executable protections. Some users may want NX
>> or expanded swapspace support without the overhead or i
On Thu, Jul 19, 2007 at 06:35:17PM +0100, Hugh Dickins wrote:
> I started from your patch. But it now seems to me a bugfix to remove
> those PageCompound tests, because they're preventing a hugetlb page
> from being marked dirty, when Ken needs it to be marked dirty so
> /proc/sys/vm/drop_caches
On Thu, Jul 19, 2007 at 06:35:17PM +0100, Hugh Dickins wrote:
I started from your patch. But it now seems to me a bugfix to remove
those PageCompound tests, because they're preventing a hugetlb page
from being marked dirty, when Ken needs it to be marked dirty so
/proc/sys/vm/drop_caches
From: William Lee Irwin III [EMAIL PROTECTED]
PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want NX
or expanded swapspace support without the overhead or instability of
highmem. For these reasons
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
>> You may rest assured that it's technically feasible. It's been done.
>> The larger obstacles to all this are nontechnical.
On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
> Back then there
On Tue, Jul 17, 2007 at 10:47:37AM -0700, William Lee Irwin III wrote:
You may rest assured that it's technically feasible. It's been done.
The larger obstacles to all this are nontechnical.
On Tue, Jul 17, 2007 at 09:33:08PM +0200, Andrea Arcangeli wrote:
Back then there was no variable order
On Sat, Jul 07, 2007 at 01:52:28AM +0200, Andrea Arcangeli wrote:
> BTW, in a parallel thread (the thread where I've been suggested to
> post this), Rik rightfully mentioned Bill once also tried to get this
> working and basically asked for the differences. I don't know exactly
> what Bill did, I
At some point in the past, I wrote:
>> If at some point one of the pro-4k stacks crowd can prove that all
>> code paths are safe, or introduce another viable alternative (such as
>> Matt's idea for extending the stack dynamically), then removing the 8k
>> stacks option makes sense.
On Mon, Jul
At some point in the past, I wrote:
If at some point one of the pro-4k stacks crowd can prove that all
code paths are safe, or introduce another viable alternative (such as
Matt's idea for extending the stack dynamically), then removing the 8k
stacks option makes sense.
On Mon, Jul 16, 2007
On Sat, Jul 07, 2007 at 01:52:28AM +0200, Andrea Arcangeli wrote:
BTW, in a parallel thread (the thread where I've been suggested to
post this), Rik rightfully mentioned Bill once also tried to get this
working and basically asked for the differences. I don't know exactly
what Bill did, I only
On Thu, Jul 05, 2007 at 01:34:25PM -0700, Jeremy Fitzhardinge wrote:
> What's the state of your stack patches? I'm still using the ones you
> posted some time ago, and they seem like useful things to have in the
> kernel. Is there anything preventing you from pushing them upstream?
Just one
On Thu, Jul 05, 2007 at 01:34:25PM -0700, Jeremy Fitzhardinge wrote:
What's the state of your stack patches? I'm still using the ones you
posted some time ago, and they seem like useful things to have in the
kernel. Is there anything preventing you from pushing them upstream?
Just one
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
> fsblock is a rewrite of the "buffer layer" (ding dong the witch is
> dead), which I have been working on, on and off and is now at the stage
> where some of the basics are working-ish. This email is going to be
> long...
Long overdue.
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
>>> c. open() flag to unlink a file before returning the fd
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
>> You probably want a tmpfile(3) -like affair which never has a
>> pathname to begin wit
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
c. open() flag to unlink a file before returning the fd
On Jun 19, 2007, at 11:08:24, William Lee Irwin III wrote:
You probably want a tmpfile(3) -like affair which never has a
pathname to begin with. It could be useful
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote:
fsblock is a rewrite of the buffer layer (ding dong the witch is
dead), which I have been working on, on and off and is now at the stage
where some of the basics are working-ish. This email is going to be
long...
Long overdue. Thank
William Lee Irwin III wrote:
>> I presumed an ELF note or extended filesystem attributes were already
>> in place for this sort of affair. It may be that the model implemented
>> is so restrictive that users are forbidden to create new executables,
>> in which case
On 6/19/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> If the policy forbidding self-modifying code lacks a method of
>> exempting programs such as JIT interpreters (which I doubt) then
>> it's a problem. I'm with Alan on this one.
On Tue, Jun 19, 2007 at 11:16:29
On 6/19/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
If the policy forbidding self-modifying code lacks a method of
exempting programs such as JIT interpreters (which I doubt) then
it's a problem. I'm with Alan on this one.
On Tue, Jun 19, 2007 at 11:16:29PM -0400, Albert Cahalan wrote
William Lee Irwin III wrote:
I presumed an ELF note or extended filesystem attributes were already
in place for this sort of affair. It may be that the model implemented
is so restrictive that users are forbidden to create new executables,
in which case using a different model is certainly
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
> Right now, Linux isn't all that friendly to JIT emulators.
> Here are the problems and suggestions to improve the situation.
> There is an SE Linux execmem restriction that enforces W^X.
> Assuming you don't wish to just disable SE
On Fri, Jun 08, 2007 at 02:35:22AM -0400, Albert Cahalan wrote:
Right now, Linux isn't all that friendly to JIT emulators.
Here are the problems and suggestions to improve the situation.
There is an SE Linux execmem restriction that enforces W^X.
Assuming you don't wish to just disable SE
On Sun, 17 Jun 2007, Matt Mackall wrote:
>> Is it? Last I looked it had reverted to handing out reverse-contiguous
>> pages.
On Sun, Jun 17, 2007 at 07:08:41PM -0700, Christoph Lameter wrote:
> I thought that was fixed? Bill Irwin was working on it.
> But the contiguous pages usually only work
On Sun, 17 Jun 2007, Matt Mackall wrote:
Is it? Last I looked it had reverted to handing out reverse-contiguous
pages.
On Sun, Jun 17, 2007 at 07:08:41PM -0700, Christoph Lameter wrote:
I thought that was fixed? Bill Irwin was working on it.
But the contiguous pages usually only work shortly
On Thu, Jun 14, 2007 at 03:57:25PM +0100, Mark Fortescue wrote:
> Benh's ptep_set_access_flags() patch needs to be applied in order to get
> anyware with sun4c for all kernels >= linux-2.6.15. If not applied, you
> will be lucky to get sash running as your init and even that will have
> very
On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote:
> They apear as soon as simpleinit starts up. Somtimes I get to a login
> prompt before seeing any. Other times, commands in the simpleinit rc
> script fail.
> They do apear to be random. If a command failes, you re-run the command
On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote:
They apear as soon as simpleinit starts up. Somtimes I get to a login
prompt before seeing any. Other times, commands in the simpleinit rc
script fail.
They do apear to be random. If a command failes, you re-run the command
On Thu, Jun 14, 2007 at 03:57:25PM +0100, Mark Fortescue wrote:
Benh's ptep_set_access_flags() patch needs to be applied in order to get
anyware with sun4c for all kernels = linux-2.6.15. If not applied, you
will be lucky to get sash running as your init and even that will have
very limitit
On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote:
> The random seg faults on x86_64 is interesting as I have been getting
> random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have
> not yet tried to track it down. All I know at present is that it is not a
>
On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote:
The random seg faults on x86_64 is interesting as I have been getting
random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have
not yet tried to track it down. All I know at present is that it is not a
problem
On Tue, Jun 12, 2007 at 12:20:52AM -0600, Eric W. Biederman wrote:
> Does this perhaps need to be:
>> diff --git a/ipc/shm.c b/ipc/shm.c
>> index 4fefbad..8d2672d 100644
>> --- a/ipc/shm.c
>> +++ b/ipc/shm.c
>> @@ -254,8 +254,10 @@ struct mempolicy *shm_get_policy(struct vm_area_struct
>> *vma,
On Tue, Jun 12, 2007 at 12:20:52AM -0600, Eric W. Biederman wrote:
Does this perhaps need to be:
diff --git a/ipc/shm.c b/ipc/shm.c
index 4fefbad..8d2672d 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -254,8 +254,10 @@ struct mempolicy *shm_get_policy(struct vm_area_struct
*vma, unsigned long
On Mon, Jun 11, 2007 at 09:30:20PM -0700, Andrew Morton wrote:
> Can we just double-check the refcounting please?
The refcounting for mpol's doesn't look good in general. I'm more
curious as to what releases the refcounts. alloc_page_vma(), for
instance, does get_vma_policy() which eventually
On Mon, Jun 11, 2007 at 04:34:54PM -0500, Adam Litke wrote:
> Here's another breakage as a result of shared memory stacked files :(
> The NUMA policy for a VMA is determined by checking the following (in
> the order given):
> 1) vma->vm_ops->get_policy() (if defined)
> 2) vma->vm_policy (if
On Thu, Jun 07, 2007 at 07:35:51PM -0700, William Lee Irwin III wrote:
>> + PAE is required for NX support, and furthermore enables
>> + larger swapspace support for non-overcommit purposes. It
>> + has the cost of more pagetable lookup overhead, and also
>&
On Thu, Jun 07, 2007 at 07:35:51PM -0700, William Lee Irwin III wrote:
+ PAE is required for NX support, and furthermore enables
+ larger swapspace support for non-overcommit purposes. It
+ has the cost of more pagetable lookup overhead, and also
+ consumes more pagetable
On Mon, Jun 11, 2007 at 04:34:54PM -0500, Adam Litke wrote:
Here's another breakage as a result of shared memory stacked files :(
The NUMA policy for a VMA is determined by checking the following (in
the order given):
1) vma-vm_ops-get_policy() (if defined)
2) vma-vm_policy (if defined)
3)
On Mon, Jun 11, 2007 at 09:30:20PM -0700, Andrew Morton wrote:
Can we just double-check the refcounting please?
The refcounting for mpol's doesn't look good in general. I'm more
curious as to what releases the refcounts. alloc_page_vma(), for
instance, does get_vma_policy() which eventually
On Sun, Jun 10, 2007 at 04:26:07PM +1000, Paul Mackerras wrote:
> If you don't think we should be bound by POSIX, then you are perfectly
> free to go off and write your own research kernel with whatever
> interface you want, and no programs available to run on it. :)
This isn't fair to research
On Sun, Jun 10, 2007 at 04:26:07PM +1000, Paul Mackerras wrote:
If you don't think we should be bound by POSIX, then you are perfectly
free to go off and write your own research kernel with whatever
interface you want, and no programs available to run on it. :)
This isn't fair to research
On Sat, Jun 09, 2007 at 09:10:51PM -0700, dean gaudet wrote:
> ok i've narrowed it some... maybe.
> in commit 8ef8286689c6b5bc76212437b85bdd2ba749ee44 things work fine, numa
> policy is respected...
> the very next commit bc56bba8f31bd99f350a5ebfd43d50f411b620c7 breaks shm
> badly causing the
On Sat, Jun 09, 2007 at 09:10:51PM -0700, dean gaudet wrote:
ok i've narrowed it some... maybe.
in commit 8ef8286689c6b5bc76212437b85bdd2ba749ee44 things work fine, numa
policy is respected...
the very next commit bc56bba8f31bd99f350a5ebfd43d50f411b620c7 breaks shm
badly causing the test
On Fri, Jun 08, 2007 at 10:07:52AM +0200, Mikael Pettersson wrote:
> Is this really needed? I can see why VMSPLIT_{2,3}G_OPT would
> depend on !HIGHMEM, but why would they depend on !X86_PAE?
The only reason they depend on !HIGHMEM is because handling for
1GB-unaligned splits is unimplemented for
On Fri, Jun 08, 2007 at 10:07:52AM +0200, Mikael Pettersson wrote:
Is this really needed? I can see why VMSPLIT_{2,3}G_OPT would
depend on !HIGHMEM, but why would they depend on !X86_PAE?
The only reason they depend on !HIGHMEM is because handling for
1GB-unaligned splits is unimplemented for
William Lee Irwin III wrote:
>> Beg your pardon? Are you reading the patch description correctly?
On Thu, Jun 07, 2007 at 08:44:09PM -0700, H. Peter Anvin wrote:
> I mean, with your patch CONFIG_HIGHMEM4G versus CONFIG_HIGHMEM64G really
> don't make sense as separate selections
William Lee Irwin III wrote:
>> !CONFIG_X86_PAE && CONFIG_HIGHMEM64G doesn't make sense and is not allowed
>> by this patch. CONFIG_X86_PAE && !CONFIG_HIGHMEM64G works here.
On Thu, Jun 07, 2007 at 08:38:22PM -0700, H. Peter Anvin wrote:
> But what's the poin
On Thu, 7 Jun 2007 19:35:51 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> PAE is useful for more than supporting more than 4GB RAM. It supports
>> expanded swapspace and NX executable protections. Some users may want
>> NX or expanded swapspace supp
PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want
NX or expanded swapspace support without the overhead or instability
of highmem. For these reasons, the following patch divorces
CONFIG_X86_PAE from
Robert P. J. Day wrote:
>> although it's not clear where in the source tree are the invocations
>> that would actually make a difference to a MIPS system, which is why
>> i've CC'ed ralf on this. i'm sure he can clear this up. :-)
On Thu, Jun 07, 2007 at 10:32:29AM -0700, H. Peter Anvin wrote:
>
On Thu, Jun 07, 2007 at 12:19:22AM -0700, Andrew Morton wrote:
> hm, OK, this seems to work:
[...]
> -#ifdef CONFIG_HIGHMEM
> +#if defined(CONFIG_HIGHMEM) && defined(CONFIG_ARCH_POPULATES_NODE_MAP)
> return movable_zone == ZONE_HIGHMEM;
> #else
> return 0;
> _
> (the first ifdef is
On Thu, Jun 07, 2007 at 12:01:25AM -0700, Andrew Morton wrote:
>> config, please?
On Thu, Jun 07, 2007 at 12:04:07AM -0700, William Lee Irwin III wrote:
> It's the sparc32 defconfig. Included below for completeness.
The error output looks like the following.
-- wli
$
On Wed, 6 Jun 2007 23:55:44 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> The fully-applied tree fails with a link error having to do with
>> movable_zone. I'm not entirely sure what arches are supposed to do
>> about that.
On Thu, Jun 07, 2007 at 12:01:2
On Wed, 6 Jun 2007 23:42:31 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> create-the-zone_movable-zone.patch breaks the build on sparc32.
On Wed, Jun 06, 2007 at 11:51:31PM -0700, Andrew Morton wrote:
> Nope, there are no instances of GFP_HIGH_MOVABLE in the tree onc
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
> - Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem
> trees were repulled, several bad patches were dropped, a few were
On Wed, Jun 06, 2007 at 06:09:24PM -0700, Andrew Morton wrote:
> ooh, yes, lockdep_init() really does want to be called before anything
> else.
> So do we take it that this code hasn't been tested with lockdep? Please
> don't forget that step - lockdep finds some pretty nasty bugs sometimes.
>
PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want
NX or expanded swapspace support without the overhead or instability
of highmem. For these reasons, the following patch divorces
CONFIG_X86_PAE from
On Thu, 7 Jun 2007 19:35:51 -0700 William Lee Irwin III [EMAIL PROTECTED]
wrote:
PAE is useful for more than supporting more than 4GB RAM. It supports
expanded swapspace and NX executable protections. Some users may want
NX or expanded swapspace support without the overhead or instability
William Lee Irwin III wrote:
!CONFIG_X86_PAE CONFIG_HIGHMEM64G doesn't make sense and is not allowed
by this patch. CONFIG_X86_PAE !CONFIG_HIGHMEM64G works here.
On Thu, Jun 07, 2007 at 08:38:22PM -0700, H. Peter Anvin wrote:
But what's the point?
If you're going to divorce these, at least
William Lee Irwin III wrote:
Beg your pardon? Are you reading the patch description correctly?
On Thu, Jun 07, 2007 at 08:44:09PM -0700, H. Peter Anvin wrote:
I mean, with your patch CONFIG_HIGHMEM4G versus CONFIG_HIGHMEM64G really
don't make sense as separate selections anymore.
I thought
On Wed, Jun 06, 2007 at 06:09:24PM -0700, Andrew Morton wrote:
ooh, yes, lockdep_init() really does want to be called before anything
else.
So do we take it that this code hasn't been tested with lockdep? Please
don't forget that step - lockdep finds some pretty nasty bugs sometimes.
This?
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/
- Basically a bugfixed version of 2.6.22-rc4-mm1. None of the subsystem
trees were repulled, several bad patches were dropped, a few were
On Wed, 6 Jun 2007 23:42:31 -0700 William Lee Irwin III [EMAIL PROTECTED]
wrote:
create-the-zone_movable-zone.patch breaks the build on sparc32.
On Wed, Jun 06, 2007 at 11:51:31PM -0700, Andrew Morton wrote:
Nope, there are no instances of GFP_HIGH_MOVABLE in the tree once all
patches
On Wed, 6 Jun 2007 23:55:44 -0700 William Lee Irwin III [EMAIL PROTECTED]
wrote:
The fully-applied tree fails with a link error having to do with
movable_zone. I'm not entirely sure what arches are supposed to do
about that.
On Thu, Jun 07, 2007 at 12:01:25AM -0700, Andrew Morton wrote
On Thu, Jun 07, 2007 at 12:01:25AM -0700, Andrew Morton wrote:
config, please?
On Thu, Jun 07, 2007 at 12:04:07AM -0700, William Lee Irwin III wrote:
It's the sparc32 defconfig. Included below for completeness.
The error output looks like the following.
-- wli
$ quilt top
On Thu, Jun 07, 2007 at 12:19:22AM -0700, Andrew Morton wrote:
hm, OK, this seems to work:
[...]
-#ifdef CONFIG_HIGHMEM
+#if defined(CONFIG_HIGHMEM) defined(CONFIG_ARCH_POPULATES_NODE_MAP)
return movable_zone == ZONE_HIGHMEM;
#else
return 0;
_
(the first ifdef is just there
Robert P. J. Day wrote:
although it's not clear where in the source tree are the invocations
that would actually make a difference to a MIPS system, which is why
i've CC'ed ralf on this. i'm sure he can clear this up. :-)
On Thu, Jun 07, 2007 at 10:32:29AM -0700, H. Peter Anvin wrote:
x86
On Wed, 6 Jun 2007 09:30:53 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> Something brings down i386/qemu before even earlyprintk can handle.
>> Bisection has narrowed it down to patch 1140 after everything got
>> renumbered by peterz' fix for mm-variable-lengt
On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
> I do not believe this is Nick's problem. I encountered the same issue and
> the bisect ended up here;
> # BISECT HERE
> mm-variable-length-argument-support.patch
> mm-variable-length-argument-support-fix.patch
> # BISECT BAD
> Reverting
On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> - Somebody broke it on my powerpc G5, but I didn't have time to do yet
> another bisection yet.
> - There's a lengthy patch series here from
On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
- Somebody broke it on my powerpc G5, but I didn't have time to do yet
another bisection yet.
- There's a lengthy patch series here from
On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
I do not believe this is Nick's problem. I encountered the same issue and
the bisect ended up here;
# BISECT HERE
mm-variable-length-argument-support.patch
mm-variable-length-argument-support-fix.patch
# BISECT BAD
Reverting those
On Wed, 6 Jun 2007 09:30:53 -0700 William Lee Irwin III [EMAIL PROTECTED]
wrote:
Something brings down i386/qemu before even earlyprintk can handle.
Bisection has narrowed it down to patch 1140 after everything got
renumbered by peterz' fix for mm-variable-length-argument-support.patch
From: Alan Cox <[EMAIL PROTECTED]>
Date: Mon, 4 Jun 2007 14:30:05 +0100
>> There are PCMCIA controllers and PCI/PCMCIA/Cardbus adapters for the
>> Sparc platform I thought ?
On Mon, Jun 04, 2007 at 02:22:43PM -0700, David Miller wrote:
> The 32-bit sparc port has some but those PCMCIA controllers
On Mon, Jun 04, 2007 at 10:50:41AM -0700, Linus Torvalds wrote:
> The exception is if you use the memory allocator as a "ID allocator", but
> quite frankly, if you use a size of zero, it's your own damn problem.
> Insane code is not an argument for insane behaviour.
> If people can't be bothered
On Fri, 1 Jun 2007 21:45:15 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
>> That would have to occur with objects that are repeatedly allocated and
>> then linked toghether etc. Linking typicallty requires a listhead so its
>> typically difficult to do zero length objects.
On Fri,
On Fri, 1 Jun 2007 21:45:15 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
That would have to occur with objects that are repeatedly allocated and
then linked toghether etc. Linking typicallty requires a listhead so its
typically difficult to do zero length objects.
On Fri, Jun 01,
On Mon, Jun 04, 2007 at 10:50:41AM -0700, Linus Torvalds wrote:
The exception is if you use the memory allocator as a ID allocator, but
quite frankly, if you use a size of zero, it's your own damn problem.
Insane code is not an argument for insane behaviour.
If people can't be bothered to
From: Alan Cox [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:30:05 +0100
There are PCMCIA controllers and PCI/PCMCIA/Cardbus adapters for the
Sparc platform I thought ?
On Mon, Jun 04, 2007 at 02:22:43PM -0700, David Miller wrote:
The 32-bit sparc port has some but those PCMCIA controllers aren't
On Wed, May 30, 2007 at 10:00:34AM -0400, Mathieu Desnoyers wrote:
>>> + if (prof_on)
>>> + BUG_ON(cond_call_arm("profile_on"));
* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
>> What's the point of this BUG_ON()? The condition is a priori impos
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
>> Its ->wait_runtime will drop less significantly, which lets it be
>> inserted in rb-tree much to the left of those 1000 tasks (and which
>> indirectly lets it gain back its fair share during subsequent
>> schedule cycles).
>>
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
>> Temporarily, yes. All this only works when averaged out.
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
> So essentially when we calculate delta_mine component for each of those
> 10
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
>> It's not all that tricky.
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
> Hmm ..the fact that each task runs for a minimum of 1 tick seems to
> complicate the matters to me (when doing gr
On Wed, May 30, 2007 at 09:09:26PM -0700, William Lee Irwin III wrote:
It's not all that tricky.
On Thu, May 31, 2007 at 11:18:28AM +0530, Srivatsa Vaddagiri wrote:
Hmm ..the fact that each task runs for a minimum of 1 tick seems to
complicate the matters to me (when doing group fairness
On Wed, May 30, 2007 at 11:36:47PM -0700, William Lee Irwin III wrote:
Temporarily, yes. All this only works when averaged out.
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
So essentially when we calculate delta_mine component for each of those
1000 tasks, we will find
On Thu, May 31, 2007 at 02:03:53PM +0530, Srivatsa Vaddagiri wrote:
Its -wait_runtime will drop less significantly, which lets it be
inserted in rb-tree much to the left of those 1000 tasks (and which
indirectly lets it gain back its fair share during subsequent
schedule cycles).
Hmm ..is
On Wed, May 30, 2007 at 10:00:34AM -0400, Mathieu Desnoyers wrote:
+ if (prof_on)
+ BUG_ON(cond_call_arm(profile_on));
* William Lee Irwin III ([EMAIL PROTECTED]) wrote:
What's the point of this BUG_ON()? The condition is a priori impossible.
On Thu, May 31, 2007 at 05:12:58PM
1 - 100 of 815 matches
Mail list logo
