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 m
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 gi
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-lo
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 yo
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 fo
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
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 o
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 d
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 t
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 o
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,
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 th
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
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 us
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 a
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 L
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 sho
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 lim
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 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
> probl
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, uns
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 take
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
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 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 ke
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 tes
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 selec
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
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
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 CONFIG_HIG
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 jus
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.
-- wl
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
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.
> Thi
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-
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
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, J
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
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).
>> Hm
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 ta
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 doi
On Wed, May 30, 2007 at 01:13:59PM -0700, William Lee Irwin III wrote:
>> The step beyond was to show how nice numbers can be done with all that
>> hierarchical task grouping so they have global effects instead of
>> effects limited to the scope of the narrowest grouping hiera
On 5/31/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>> Please give a very very strong rationale why you want it. Did you actually
>> run into such a situation yourself yet?
On Thu, May 31, 2007 at 09:09:58AM +1000, Dave Airlie wrote:
> Funnily enough I have just today with an app I have which uses 1
On Wed, May 30, 2007 at 01:00:30PM -0700, Linus Torvalds wrote:
>> Which *could* be something as simple as saying "bit 30 in the file
>> descriptor specifies a separate fd space" along with some flags to make
>> open and friends return those separate fd's. That makes them useless for
>> "select(
On Wed, May 30, 2007 at 02:27:52PM -0700, Linus Torvalds wrote:
> Well, don't think of it as a special case at all: think of bit 30 as a
> "the user asked for a non-linear fd".
> In fact, to make it effective, I'd suggest literally scrambling the low
> bits (using, for example, some silly per-boo
On Wed, May 30, 2007 at 10:00:34AM -0400, Mathieu Desnoyers wrote:
> Use conditional calls with lower d-cache hit in optimized version as a
> condition for scheduler profiling call.
[...]
> + if (prof_on)
> + BUG_ON(cond_call_arm("profile_on"));
What's the point of this BUG_ON()? T
On Sat, May 26, 2007 at 08:41:12AM -0700, William Lee Irwin III wrote:
>> The smpnice affair is better phrased in terms of task weighting. It's
>> simple to honor nice in such an arrangement. First unravel the
>> grouping hierarchy, then weight by nice. This looks lik
On Wed, May 30, 2007 at 12:14:55AM -0700, Andrew Morton wrote:
> So how do we do this?
> Is there any sneaky way in which we can modify the kernel so that this new
> code gets exercised more? Obviously, tossing init into some default
> system-wide container would be a start. But I wonder if we ca
On Mon, May 28, 2007 at 10:09:19PM +0530, Srivatsa Vaddagiri wrote:
> What do these task weights control? Timeslice primarily? If so, I am not
> sure how well it can co-exist with cfs then (unless you are planning to
> replace cfs with a equally good interactive/fair scheduler :)
> I would be very
William Lee Irwin III wrote:
>> Lag is the deviation of a task's allocated CPU time from the CPU time
>> it would be granted by the ideal fair scheduling algorithm (generalized
>> processor sharing; take the limit of RR with per-task timeslices
>> proportional to lo
William Lee Irwin III wrote:
>> Lag should be considered in lieu of load because lag
On Sun, May 27, 2007 at 11:29:51AM +1000, Peter Williams wrote:
> What's the definition of lag here?
Lag is the deviation of a task's allocated CPU time from the CPU time
it would be grante
Srivatsa Vaddagiri wrote:
>> Ingo/Peter, any thoughts here? CFS and smpnice probably is "broken"
>> with respect to such example as above albeit for nice-based tasks.
On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
> See above. I think that faced with cpu affinity use by the sys
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> I remember. It was far beyond "slightly async;" they would drift
>> minutes apart during reasonable amounts of uptime, though it would
>> take at least several days to drift so far (I don't recall how l
On Fri, May 25, 2007 at 01:19:44AM -0700, William Lee Irwin III wrote:
>> I remember. It was far beyond "slightly async;" they would drift
>> minutes apart during reasonable amounts of uptime, though it would take
>> at least several days to drift so far (I don't
On Fri, May 25, 2007 at 10:08:27AM +0200, Ingo Molnar wrote:
> Andi, Andrew, do you remember why we disabled TSCs on NUMAQ? It was
> slightly async between CPUs, right? In that case we should try the patch
> below.
I remember. It was far beyond "slightly async;" they would drift
minutes apart du
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
> - A new readahead patch series. This needs serious review and performance
> testing please.
> - Added Ingo's CFS CPU scheduler
> - Xen dom-U
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
> - A new readahead patch series. This needs serious review and performance
> testing please.
> - Added Ingo's CFS CPU scheduler
> - Xen dom-U
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
> - A new readahead patch series. This needs serious review and performance
> testing please.
> - Added Ingo's CFS CPU scheduler
> - Xen dom-U
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
> - A new readahead patch series. This needs serious review and performance
> testing please.
> - Added Ingo's CFS CPU scheduler
> - Xen dom-U
On Wed, May 23, 2007 at 12:42:33AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
> - A new readahead patch series. This needs serious review and performance
> testing please.
> - Added Ingo's CFS CPU scheduler
> - Xen dom-U
On Wednesday 23 May 2007 10:28, Bill Davidsen wrote:
>>> kernel2.6.21-cfs-v132.6.21-ck2
>>> a)194464254669
>>> b)54159124
>> Everyone seems to like ck2, this makes it look as if the video display
>> would be really pretty unusable. While sd-0.48 does show an occasion
On Mon, May 21, 2007 at 10:04:10PM -0700, William Lee Irwin III wrote:
>> The size isn't the advantage being cited; I'd actually expect the net
>> result to be larger. It's the control over the layout of the metadata
>> for cache locality and even things
On Mon, May 21, 2007 at 06:39:51PM -0700, William Lee Irwin III wrote:
>> address (virtual and physical are trivially inter-convertible), mock
>> up something akin to what filesystems do for anonymous pages, etc.
>> The real objection everyone's going to have is that drive
On Mon, May 21, 2007 at 11:27:42AM +0200, Nick Piggin wrote:
>> ... yeah, something like that would bypass
On Mon, May 21, 2007 at 05:43:16PM -0500, Matt Mackall wrote:
> As long as we're throwing out crazy unpopular ideas, try this one:
> Divide struct page in two such that all the most commonly
On Fri, 2007-05-18 at 09:37 +0530, Balbir Singh wrote:
>> oops! I wonder if AIM7 creates too many processes and exhausts all
>> memory. I've seen a case where during an upgrade of my tetex on my
>> laptop, the setup process failed and continued to fork processes
>> filling up 4GB of swap.
On Mon,
> From: William Lee Irwin III <[EMAIL PROTECTED]>
> Date: Mon, 21 May 2007 04:37:47 -0700
>> This could be awkward with allocation requirements. How about an
>> open-addressed hash table? It can be made so large as to never
>> need to expand in advance with a ve
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> cfs should probably consider aggregate lag as opposed to aggregate
>> weighted load. Mainline's convergence to proper CPU bandwidth
>> distributions on SMP (e.g. N+1 tasks of equal nice on N cpus) is
>>
On Sat, May 19, 2007 at 03:26:49PM -0700, David Miller wrote:
> I think we may be able to fix that one without making the
> counter larger, it's silly overhead for such an extreme
> case IMHO.
> Perhaps it might be possible to just make the counter stick at it's
> maximum, and when it's there we ha
On Mon, May 21, 2007 at 01:08:13AM -0700, William Lee Irwin III wrote:
>> Choosing k distinct integers (mem_map array indices) from the interval
>> [0,n-1] results in k(n-k+1)/n non-adjacent intervals of contiguous
>> array indices on average. The average interval length is
>
On Thu, May 17, 2007 at 07:26:38PM -0400, Bill Davidsen wrote:
> I have posted the results of my initial testing, measuring IPC rates
> using various schedulers under no load, limited nice load, and heavy
> load at nice 0.
> http://www.tmr.com/~davidsen/ctxbench_testing.html
Kernel compiles are
On Sat, May 19, 2007 at 03:27:54PM +0200, Dmitry Adamushko wrote:
> Just an(quick) another idea. Say, the load balancer would consider not
> only p->load_weight but also something like Tw(task) =
> (time_spent_on_runqueue / total_task's_runtime) * some_scale_constant
> as an additional "load" compo
William Lee Irwin III a ?crit :
>> The proper way to do this is to convert the large system hashtable
>> users to use some data structure / algorithm other than hashing by
>> separate chaining.
On Sat, May 19, 2007 at 08:41:01PM +0200, Eric Dumazet wrote:
> No thanks. This
On Sun, May 20, 2007 at 01:46:47AM -0700, William Lee Irwin III wrote:
>> The lack of consideration of the average case. I'll see what I can smoke
>> out there.
On Sun, May 20, 2007 at 11:25:52AM +0200, Nick Piggin wrote:
> I _am_ considering the average case, and I consider t
On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote:
>> The cache cost argument is specious. Even misaligned, smaller is
>> smaller.
On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote:
> Of course smaller is smaller ;) Why would that make the cache
On Sat, 19 May 2007 11:15:01 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> Much the same holds for the atomic_t's; 32 + PAGE_SHIFT is
>> 44 bits or more, about as much as is possible, and one reference per
>> page per page is not even feasible. Full-leng
On Fri, May 18, 2007 at 11:54:54AM +0200, Eric Dumazet wrote:
> alloc_large_system_hash() is called at boot time to allocate space
> for several large hash tables.
> Lately, TCP hash table was changed and its bucketsize is not a
> power-of-two anymore.
> On most setups, alloc_large_system_hash() al
On Fri, May 18, 2007 at 11:14:26AM -0700, Christoph Lameter wrote:
>> Right. That would simplify the calculations.
On Sat, May 19, 2007 at 03:25:30AM +0200, Nick Piggin wrote:
> It isn't the calculations I'm worried about, although they'll get simpler
> too. It is the cache cost.
The cache cost a
On Fri, 18 May 2007, Nick Piggin wrote:
>> If we add 8 bytes to struct page on 64-bit machines, it becomes 64 bytes,
>> which is quite a nice number for cache purposes.
>> However we don't have to let those 8 bytes go to waste: we can use them
>> to store the virtual address of the page, which kind
On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
>> So i've added a yield workaround to -v12, which makes it work similar to
>> how the vanilla scheduler and SD does it. (Xorg has been notified and
>> this bug should be fixed there too. This took some time to debug because
>> the 3D
On Tue, May 15, 2007 at 10:41:06PM -0700, dean gaudet wrote:
> prior to 2.6.21 i could "numactl --interleave=all" and use SHM_HUGETLB and
> the interleave policy would be respected. as of 2.6.21 it doesn't seem to
> respect the policy on SHM_HUGETLB request.
> see test program below.
> output fr
On Tue, May 15, 2007 at 07:51:05PM +0100, Hugh Dickins wrote:
> No other architecture calls check_pgt_cache() from within flush_tlb_mm(),
> and i386 is already calling check_pgt_cache() from the usual places,
> tlb_finish_mmu() and cpu_idle() (the latter being odd, but not unusual).
> flush_tlb_mm(
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> [...] I'm suspicious of EEVDF's timekeeping now as well.
On Mon, May 14, 2007 at 02:04:05PM +0200, Ingo Molnar wrote:
> well, EEVDF is a paper-only academic scheduler, one out of thousands
> that never touched rea
On Mon, May 14, 2007 at 12:31:20PM +0200, Ingo Molnar wrote:
>>> please clarify - exactly what is a mistake? Thanks,
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> The variability in ->fair_clock advancement rate was the mistake, at
>> least according to my
On Mon, May 14, 2007 at 04:05:00AM -0700, William Lee Irwin III wrote:
>> The variability in ->fair_clock advancement rate was the mistake, at
>> least according to my way of thinking. The queue's virtual time clock
>> effectively stops under sufficiently high load, po
clock: task's wait
>>> time on runqueue and sleep time outside the runqueue (both reflected in
>>> p->wait_run_time).
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> It's not hard to see that that's a mistake. [...]
On Mon, May 14, 2007 at
On Mon, May 14, 2007 at 02:03:58PM +0530, Srivatsa Vaddagiri wrote:
> I have been brooding over how fair clock is computed/used in
> CFS and thought I would ask the experts to avoid wrong guesses!
> As I understand, fair_clock is a monotonously increasing clock which
> advances at a pace inve
On Fri, 11 May 2007, William Lee Irwin III wrote:
>> Christoph wants to update the core quicklist code or have me update
>> it according to the cached precomputed value scheme I outlined in a
>> prior post before its initial merge. I'll prepare all the patches for
>>
At some point in the past, Hugh Dickins wrote:
>>> I'm guessing (haven't rechecked source) that the cpu_idle() call comes
>>> about because the top level pgd of a process gets freed very late in
>>> its exit, and after a great flurry of processes have just exited,
>>> perhaps there was nothing to f
On Thu, 10 May 2007, William Lee Irwin III wrote:
>> Looking more closely at it, the entire attempt to avoid struct page
>> pointers is far beyond pointless. The freeing functions unconditionally
>> require struct page pointers to either be passed or computed and the
>&g
On Thu, May 10, 2007 at 05:07:02PM -0700, William Lee Irwin III wrote:
> I described it as motivated by such, not really correctly handling it.
> I didn't bother analyzing it for correctness. I'm not surprised at all
> that the TLB flush can be missed where it now stands in th
On Thu, May 10, 2007 at 05:07:02PM -0700, William Lee Irwin III wrote:
> quicklist_free() with unflushed TLB entries admits speculation through
> the pagetable entries corresponding to the list links. So tlb_finish_mmu()
> is the place to call quicklist_free() on pagetables. This
1 - 100 of 408 matches
Mail list logo
