On Wed, Mar 28, 2007 at 02:38:55PM -0700, Christoph Lameter wrote:
> No that was described in the patch. Quote:
> "i386 only provides support for caching constructed pgd and pmds. These
> are comparatively rare to ptes so it is no surprise that the current
> approach has only minimal effect.
On Wed, 28 Mar 2007, William Lee Irwin III wrote:
>> Getting the relevant results without tremendous amounts of noise from
>> other kernel activity needs something like lmbench's fault and fork()
>> microbenchmarks. Also, /proc/profile and/or oprofile results would be
>&
[... kernel compile garbage snipped ...]
On Wed, Mar 28, 2007 at 02:05:54PM -0700, Christoph Lameter wrote:
> Seems that there is a slight benefit but its also barely above noise
> level.
I already went over the methodological issues with kernel compiles.
You may be able to prove this, but not t
On Wed, Mar 28, 2007 at 01:12:56PM -0700, Christoph Lameter wrote:
> The benefit of preconstructed pgds and pmds in the i386 arch code seem to
> be debatable. The performance measurements indicate that there may be a slight
> benefit but it seems to almost vanish in the noise ratio.
> Method used (
On Mon, Mar 26, 2007 at 10:26:51AM -0800, Andrew Morton wrote:
> b) we understand why the below simple modification crashes i386.
This doesn't crash i386 in qemu here on a port of the quicklist patches
to 2.6.21-rc5-mm2. I suppose I'll have to dump it on some real hardware
to see if I can reproduc
On Mon, Mar 26, 2007 at 09:16:27PM -0800, Andrew Morton wrote:
> - This is the same as 2.6.12-rc5-mm1, except the staircase deadline CPU
> scheduler has been added.
This boots without incident on the Altix I've got where prior versions
of RSDL all had issues. Count RSDL as fixed here.
-- wli
-
On Mon, Mar 26, 2007 at 10:26:51AM -0800, Andrew Morton wrote:
> a) it has been demonstrated that this patch is superior to simply removing
>the quicklists and
Not that clameter really needs my help, but I agree with his position
on several fronts, and advocate accordingly, so here is where I'
On Sat, 2007-03-24 at 23:09 +0100, Miklos Szeredi wrote:
>>> Dirty page accounting/limiting doesn't work for nonlinear mappings, so
>>> for non-ram backed filesystems emulate with linear mappings. This
>>> retains ABI compatibility with previous kernels at minimal code cost.
>>> All known users of
nd I don't see why. It
>>> makes me wonder if we have a use-after-free which is hidden by the presence
>>> of the quicklist buffering or something.
On Fri, Mar 23, 2007 at 04:29:20AM -0700, William Lee Irwin III wrote:
>> Sorry I flubbed the first message. Anyway this doe
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
>> Lack of compiletesting beyond x86-64 in all probability.
On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote:
> Ok, this will go kablamo on Power then even if it compiles. I don't
> consider it a fundamental proble
On Fri, 23 Mar 2007, Ken Chen wrote:
> >-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> >-unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long
> >addr,
> >-unsigned long len, unsigned long pgoff, unsigned long flags);
> >-#else
> >-static unsigned long
> >+unsigned long
>
On Fri, Mar 23, 2007 at 01:44:38AM -0700, Ken Chen wrote:
> I think we have enough infrastructure currently in hugetlbfs to
> implement what Adam wants for something like a /dev/hugetlb char
> device (except we can't afford to have a zero hugetlb page since it
> will be too costly on some arch).
>
t;> makes me wonder if we have a use-after-free which is hidden by the presence
>> of the quicklist buffering or something.
On Fri, Mar 23, 2007 at 04:29:20AM -0700, William Lee Irwin III wrote:
> Sorry I flubbed the first message. Anyway this does mean something is
> seriously wrong
On Fri, 23 Mar 2007 15:04:54 +0100 Tomas M <[EMAIL PROTECTED]> wrote:
>> I posted this yesterday but it seems people didn't understand the real
>> goal of my patch. So I will explain once more again:
>> This is a bugfix for loop.c block driver, as it currently allocates more
>> memory then it nee
On Thu, Mar 22, 2007 at 11:48:48PM -0800, Andrew Morton wrote:
> afacit that two-year-old, totally-different patch has nothing to do with my
> repeatedly-asked question. It appears to be consolidating three separate
> quicklist allocators into one common implementation.
> In an attempt to answer m
On Thu, Mar 22, 2007 at 11:48:48PM -0800, Andrew Morton wrote:
> afacit that two-year-old, totally-different patch has nothing to do with my
> repeatedly-asked question. It appears to be consolidating three separate
> quicklist allocators into one common implementation.
> In an attempt to answer m
On Fri, Mar 23, 2007 at 11:04:18AM +0100, Ingo Molnar wrote:
>> isnt this patented by MS? (which might not worry you SuSE/Novell guys,
>> but it might be a worry for the rest of the world ;-)
On Fri, Mar 23, 2007 at 11:32:44AM +0100, Nick Piggin wrote:
> Hmm, it looks like they have implemented a
On Thu, Mar 22, 2007 at 01:21:46PM -0800, Tim Chen wrote:
> I've tried running Volanomark and found a 80% regression
> with RSDL 0.31 scheduler on 2.6.21-rc4 on a 2 socket Core 2 quad cpu
> system (4 cpus per socket, 8 cpus for system).
> The results are sensitive to rr_interval. Using Con's patch
On Thu, Mar 22 2007, Eric Dumazet wrote:
>> Sure, but it's the first Tomas patch :)
On Thu, Mar 22, 2007 at 02:54:57PM +0100, Jens Axboe wrote:
> The more the reason to guide him in the direction of a right solution,
> instead of extending the current bad one!
On Thu, Mar 22 2007, Eric Dumazet wr
Adam Litke wrote:
>> We didn't want to bloat the size of the vm_ops struct for all of its
>> users.
On Thu, Mar 22, 2007 at 10:02:07AM +1100, Nick Piggin wrote:
> But vmas are surely far more numerous than vm_ops, aren't they?
It should be clarified that the pointer to the operations structure
in
On Wed, Mar 21, 2007 at 03:26:59PM -0700, William Lee Irwin III wrote:
>> My exit strategy was to make hugetlbfs an alias for ramfs when ramfs
>> acquired the necessary functionality until expand-on-mmap() was merged.
>> That would've allowed rm -rf fs/hugetlbfs/ ou
On Wed, 21 Mar 2007 14:43:48 CDT, Adam Litke said:
>> The main reason I am advocating a set of pagetable_operations is to
>> enable the development of a new hugetlb interface.
On Wed, Mar 21, 2007 at 03:51:31PM -0400, [EMAIL PROTECTED] wrote:
> Do you have an exit strategy for the *old* interface?
William Lee Irwin III wrote:
>> I'm tied up elsewhere so I won't get to it in a timely fashion. Maybe
>> in a few weeks I can start up on the first two of the bunch.
On Wed, Mar 21, 2007 at 05:51:23PM +1100, Nick Piggin wrote:
> Care to give us a hint? :)
The first is
William Lee Irwin III wrote:
>> ISTR potential ppc64 users coming out of the woodwork for something I
>> didn't recognize the name of, but I may be confusing that with your
>> patch. I can implement additional users (and useful ones at that)
>> needing this in partic
Adam Litke wrote:
>> struct vm_operations_struct * vm_ops;
>> +const struct pagetable_operations_struct * pagetable_ops;
On Wed, Mar 21, 2007 at 03:18:30PM +1100, Nick Piggin wrote:
> Can you remind me why this isn't in vm_ops?
> Also, it is going to be hugepage-only, isn't it? So should
On Mon, Mar 19, 2007 at 01:05:02PM -0700, Adam Litke wrote:
> Andrew, given the favorable review of these patches the last time
> around, would you consider them for the -mm tree? Does anyone else
> have any objections?
We need a new round of commentary for how it should integrate with
Nick Piggi
Ingo Molnar wrote:
>> what do you think about the idea i suggested: to do an x32_/x64_ prefix
>> (or _32/_64 postfix), in a brute-force way, _right away_. I.e. do not
>> have any overlap of having both arch/i386/ and arch/x86_64/ and
>> arch/x86/ - move everything to arch/x86/ right now.
On Sun
On Sat, Mar 17, 2007 at 10:41:01PM +0200, Avi Kivity wrote:
> Well, the heuristic here is that process == job. I'm not sure heuristic
> is the right name for it, but it does point out a deficieny.
> A cpu-bound process with many threads will overwhelm a cpu-bound single
> threaded threaded proce
On Sat, Mar 17, 2007 at 08:11:57AM +0100, Mike Galbraith wrote:
> On a side note, I wonder how long it's going to take to fix all the
> X/client combinations out there.
AIUI X's clients largely access it via libraries X ships, so the X
update will sweep the vast majority of them in one shot. You'l
William Lee Irwin III <[EMAIL PROTECTED]> writes:
>> I'd not mind something better than a hashtable. The fib tree may make
>> more sense than anticipated. It's truly better to switch data structures
>> completely than fiddle with e.g. hashtable sizes. However, be
On Tue, Mar 13, 2007 at 06:12:44PM -0700, William Lee Irwin III wrote:
> There are furthermore distinctions to make between fork() and execve().
> fork() stomps over the entire process address space copying pagetables
> en masse. After execve() a process incrementally faults in PTE
On Fri, Mar 16, 2007 at 07:25:53AM +1100, Nick Piggin wrote:
> I would just avoid the complexity and setup/teardown costs, and just
> use a vmalloc'ed global hash for NUMA.
This patch is not the way to go, but neither are vmalloc()'d global
hashtables. When you just happen to hash to the wrong nod
On Thu, Mar 15, 2007 at 07:19:21PM +0530, Ankita Garg wrote:
> Looking at oom_kill.c, found that the intention to not kill the selected
> process if any of its children/siblings has OOM_DISABLE set, is not being met.
> Signed-off-by: Ankita Garg <[EMAIL PROTECTED]>
> Index: ankita/linux-2.6.20.1/mm
William Lee Irwin III <[EMAIL PROTECTED]> writes:
>> Radix trees' space behavior is extremely poor in sparsely-populated
>> index spaces. There is no way they would save space or even come close
>> to the current space footprint.
On Wed, Mar 14, 2007 at 10:54:07AM -
On Wed, Mar 14, 2007 at 08:12:35AM -0600, Eric W. Biederman wrote:
> If we do dig into this more we need to consider a radix_tree to hold
> the pid values. That could replace both the pid map and the hash
> table, gracefully handle but large and small pid counts, might
> be a smidgin simpler, poss
On Wed, Mar 14, 2007 at 09:18:50AM +, Al Viro wrote:
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
> ---
> arch/sparc/mm/init.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Dave, I trust you'll pick it up until I get a git tree going.
Acked-by: William Irwin <[EMAIL PROTECTED
On Wed, Mar 14, 2007 at 10:30:59AM +0300, Pavel Emelianov wrote:
> I'm looking at how alloc_pid() works and can't understand
> one (simple/stupid) thing.
> It first kmem_cache_alloc()-s a strct pid, then calls
> alloc_pidmap() and at the end it taks a global pidmap_lock()
> to add new pid to hash.
> On Wednesday 14 March 2007, William Lee Irwin III wrote:
> >On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
> >> Now, can someone suggest a patch I can revert that might fix this?
> >> The total number of patches between 2.6.20 and 2.6.21-rc1 will have
e.
On Tue, Mar 13, 2007 at 10:07:21PM -0700, William Lee Irwin III wrote:
> 4 billion patches could be bisected in 34 boots. Between 2.6.20 and
> 2.6.21-rc1 there are only:
> $ git rev-list --no-merges v2.6.20..v2.6.21-rc1 |wc -l
> 3118
> patches, requiring 14 boots. In general
On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
> Now, can someone suggest a patch I can revert that might fix this? The
> total number of patches between 2.6.20 and 2.6.21-rc1 will have me
> building kernels to bisect this till the middle of June at this rate.
4 billion patches c
On Tue, Mar 13, 2007 at 04:47:56AM -0800, Andrew Morton wrote:
> I'm trying to remember why we ever would have needed to zero out the
> pagetable pages if we're taking down the whole mm? Maybe it's
> because "oh, the arch wants to put this page into a quicklist to
> recycle it", which is all rathe
On Mon, Mar 12, 2007 at 03:51:57PM -0700, David Miller wrote:
> Someone with some extreme patience could do the sparc 32-bit port too,
> in fact it's lacking the cached PGD update logic that x86 et al. have
> so it would even end up being a bug fix :-) This lack is why sparc32
> pre-initializes th
On Sun, 11 Mar 2007 13:28:22 +1100 "Con Kolivas" <[EMAIL PROTECTED]> wrote:
>> Well... are you advocating we change sched_yield semantics to a
>> gentler form?
On Sat, Mar 10, 2007 at 07:16:14PM -0800, Andrew Morton wrote:
> From a practical POV: our present yield() behaviour is so truly awful tha
On Sat, Mar 10, 2007 at 06:09:34PM -0800, Christoph Lameter wrote:
> i386: Convert to quicklists
> Implement the i386 management of pgd and pmds using quicklists.
I approve, though it would be nice if ptes had an interface operating
on struct page * to use.
On Sat, Mar 10, 2007 at 06:09:34PM -08
William Lee Irwin III wrote:
>> Last I checked there were limits to runtime configurability centering
>> around only supporting a compiled-in set of scheduling drivers, unless
>> Peter's taken it the rest of the way without my noticing. It's unclear
>> what yo
On Sat, 10 Mar 2007 00:26:46 -0800, William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> Oh dear. Could we bit a bit more idiomatic here? For instance,
>> something like:
On Sat, Mar 10, 2007 at 12:29:44AM -0800, David Miller wrote:
> Ok I pulled the sparc32 patch back ou
On Sat, Mar 10, 2007 at 03:17:43AM -0500, Mathieu Desnoyers wrote:
> @@ -348,7 +348,7 @@ void exit_thread(void)
> #ifndef CONFIG_SMP
> if(last_task_used_math == current) {
> #else
> - if(current_thread_info()->flags & _TIF_USEDFPU) {
> + if(test_ti_thread_flag(current_thread_info(),
William Lee Irwin III wrote:
>>>> This sort of concern is too subjective for me to have an opinion on it.
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
>>> How diplomatic.
William Lee Irwin III wrote:
>> Impoliteness doesn't accomplish anything I want
On Fri, Mar 09, 2007 at 05:18:31PM -0500, Ryan Hope wrote:
> from what I understood, there is a performance loss in plugsched
> schedulers because they have to share code
> even if pluggable schedulers is not a viable option, being able to
> choose which one was built into the kernel would be e
William Lee Irwin III wrote:
>> The short translation of my message for you is "Linus, please don't
>> LART me too hard."
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
> Right.
Given where the code originally came from, I've got bullets to d
William Lee Irwin III wrote:
>> I consider policy issues to be hopeless political quagmires and
>> therefore stick to mechanism. So even though I may have started the
>> code in question, I have little or nothing to say about that sort of
>> use for it.
>> There
On Thu, 8 Mar 2007 22:12:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>> Fix sparc TIF_USEDFPU flag atomicity
>> Non atomic update of TIF can be very dangerous, except at thread structure
>> creation time. Here I standardize the TIF_USEDFPU usage of the sparc arch.
>> Applies on 2.6.20.
>>
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> No. Really.
> I absolutely *detest* pluggable schedulers. They have a huge downside:
> they allow people to think that it's ok to make special-case schedulers.
> And I simply very fundamentally disagree.
> If you want to play with
On Fri, Mar 09, 2007 at 12:07:06PM +0300, Serge Belyshev wrote:
> If you see sched_yield() when stracing any 3d program, I suggest you
> to try this bruteforce workaround, which works fine for me,
> disable sched_yield():
May I suggest LD_PRELOAD of a library consisting of only a nopped
sched_yiel
On Fri, 2 Mar 2007, William Lee Irwin III wrote:
>> AIUI that phenomenon is universal to NUMA. Maybe it's time we
>> reexamined our locking algorithms in the light of fairness
>> considerations.
On Fri, Mar 02, 2007 at 07:15:38PM -0800, Christoph Lameter wrote:
> Th
On Fri, 2 Mar 2007 17:40:04 -0800 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> My gut feeling is to agree, but I get nagging doubts when I try to
>> think of how to boil things like [major benchmarks whose names are
>> trademarked/copyrighted/etc. censored] down t
On Fri, Mar 02, 2007 at 02:59:06PM -0800, Andrew Morton wrote:
> What is it with vendors finding MM problems and either not fixing them or
> kludging around them and not telling the upstream maintainers about *any*
> of it?
I'm not in the business of defending vendors, but a lot of times the
base
On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
> Opterons seem to be particularly prone to lock starvation where a cacheline
> gets captured in a single package for ever.
AIUI that phenomenon is universal to NUMA. Maybe it's time we
reexamined our locking algorithms in the light of
On Sun, Feb 25, 2007 at 11:01:06PM -0500, David Woodhouse wrote:
> Yeah, I did that before giving up on it for the day and going in search
> of dinner. It changes the failure mode to a BUG() in
> cache_free_debugcheck(), at line 2876 of mm/slab.c
> It smells like the pages weren't actually reserved
> From: William Lee Irwin III <[EMAIL PROTECTED]>
> Date: Sat, 24 Feb 2007 14:56:31 -0800
>> just do it on a per-directory basis so you don't intermix children
>> of different parents in some boot-time -allocated global trainwreck
>> and you're home free.
On Fri, Feb 23, 2007 at 08:24:44PM -0800, William Lee Irwin III wrote:
>> You would be better served by a data structure different from a hashtable.
On Sat, Feb 24, 2007 at 06:09:37AM +0100, Nick Piggin wrote:
> Out of curiosity, what better data structure do you have in mind for
>
On Thu, 22 Feb 2007, Pekka J Enberg wrote:
>> As suggested by William, free the actual pages in a batch so that we
>> don't keep pounding on l3->list_lock.
On Thu, Feb 22, 2007 at 03:01:30PM -0800, Christoph Lameter wrote:
> This means holding the l3->list_lock for a prolonged time period. The
>
On Fri, Feb 23, 2007 at 04:37:43PM +0100, Nick Piggin wrote:
> The dentry hash uses up 8MB for 1 million entries on my 4GB system is
> one of the biggest wasters of memory for me. Because I rarely have
> more than one or two hundred thousand dentries. And that's with
> several kernel trees worth of
On Fri, Feb 16, 2007 at 05:46:29PM -0500, Rik van Riel wrote:
> The attached patch does what I described in the other thread, it
> makes the pageout code free swap space when swap is getting full,
> by taking away the swap space from pages that get moved onto or
> back onto the active list.
> In so
On Tue, Feb 20, 2007 at 01:06:47AM +0100, Adrian Bunk wrote:
> Quoting arch/x86_64/Kconfig:
> <-- snip -->
> ...
> config NR_CPUS
> int "Maximum number of CPUs (2-256)"
> range 2 255
> ...
> <-- snip -->
> cu
> Adrian
The broadcast APIC ID clashes with the 256th cpu.
-- wli
-
On Tue, Feb 20, 2007 at 01:06:34AM +0100, Adrian Bunk wrote:
> This patch adds a proper prototype for hugetlb_get_unmapped_area() in
> include/linux/hugetlb.h.
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> This patch was already sent on:
> - 25 Nov 2006
> fs/hugetlbfs/inode.c|5 +
On Mon, Feb 19, 2007 at 10:31:34AM -0800, Adam Litke wrote:
> +struct pagetable_operations_struct {
> + int (*fault)(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long address, int write_access);
> + int (*copy_vma)(struct mm_struct *dst, struct
The smp_mb() is becaus sync_page() doesn't have PG_locked while it
accesses page_mapping(page). The comments in the patch (the entire
patch is the addition of this comment) try to explain further how
and why smp_mb() is used.
mm/filemap.c: 93595c327bbdc43fcea91b513fd750d1a73edfec
--- a/mm/filemap
On Fri, 18 Mar 2005 11:25:45 -0800 "Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
>> The sparc32 & sparc64 code needs live testing.
On Fri, Mar 18, 2005 at 12:56:17PM -0800, David S. Miller wrote:
> These patches look great Randy. I think they should go in.
> If sparc explodes, I'll clean up the mess.
On Fri, Mar 18, 2005 at 11:25:45AM -0800, Randy.Dunlap wrote:
> This is a combination of io_remap_pfn_range patches posted in the
> last week or so by Keir Fraser and me.
> This description is mostly from Keir's original post.
> This patch introduces a new interface function for mapping bus/device
On Sun, Mar 06, 2005 at 03:39:08PM +0100, Adrian Bunk wrote:
> I didn't find any possible modular usage in the kernel.
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, Mar 04, 2005 at 03:47:07AM +0100, Jesper Juhl wrote:
> Now that 2.6.11 is out the door it's time to try and submit this again.
> The following patches convert all users of verify_area to access_ok and
> the final patch then deprecates verify_area acros all archs with the
> intention of re
On Sun, Mar 06, 2005 at 03:39:08PM +0100, Adrian Bunk wrote:
> I didn't find any possible modular usage in the kernel.
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, Mar 01, 2005 at 01:44:40PM -0800, Andrew Morton wrote:
> Thanks. Many of these fixups are due to a 64-bit-resource patch in Greg's
> bk-pci tree which he has now reverted. That being said:
> - That patch will come back sometime
> - Fixes like the below make sense anyway and can be merged
On Fri, Feb 25, 2005 at 03:14:46PM +1100, David Gibson wrote:
> Andrew, Linus, please apply:
> Fix a potentially bad (although very rarely triggered) bug in the
> ppc64 hugepage code. hpte_update() did not correctly calculate the
> address for hugepages, so pte_clear() (which we use for hugepage p
On Fri, Feb 11, 2005 at 08:06:08PM +, Hugh Dickins wrote:
> My recent do_munmap hugetlb fix has proved inadequate. There are
> other places (madvise, mbind, mlock, mprotect) where split_vma is
> called. Only mprotect excludes a hugetlb vma: the others are in
> danger of splitting at a misalig
On Mon, Feb 07, 2005 at 12:00:30PM +0100, Jan Kasprzak wrote:
> Well, with Linus' patch to fs/pipe.c the situation seems to
> improve a bit, but some leak is still there (look at the "monthly" graph
> at the above URL). The server has been running 2.6.11-rc2 + patch to fs/pipe.c
> for last 8
On Fri, Feb 04, 2005 at 10:33:50AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
> - The bk-usb and bk-pci and bk-driver-core trees have been temporarily
> dropped from -mm, for they are not healthy at present.
> - After man
On Fri, Feb 04, 2005 at 02:06:05PM -0600, Mr. Berkley Shands wrote:
> Sorry, but I still crash. This time it hung the kernel so bad I had to
> powerfail to restart.
Well, that fix is needed anyway.
On Fri, Feb 04, 2005 at 02:06:05PM -0600, Mr. Berkley Shands wrote:
> Feb 4 13:43:19 eclipse kern
On Fri, Feb 04, 2005 at 04:39:02PM +, Hugh Dickins wrote:
> Patch below (against 2.6.11-rc3, applies at offset to 2.6.10) fixes
> the unmap_hugepage_range BUGs I could generate: does it fix yours?
> The hugetlb_page test in do_munmap is too permissive. It checks start
> vma, but forgets that e
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>> I wouldn't be so sure about that. SGI is already implicitly relying on
>> the parallel holding of rwsems for the lockless pagefaulting, and
>> Oracle has been pushing on mapping->tree_lock becoming an rwloc
On Fri, Jan 28, 2005 at 02:14:36PM +, Hugh Dickins wrote:
> I had imagined that top down (non-FIXED) would continue to make
> more space available, the space below the text, just cutting off
> at PAGE_SIZE. There was a more serious lower limit on ARM under
> discussion before, but ARM doesn't
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
>> [...] I wanted to start looking at fixing that because it ought to
>> hurt scalability quite a bit - and even on UP create a few unneeded
>> task-switchs. [...]
On Fri, Jan 28, 2005 at 08:38:56AM +0100, Ingo Molnar wrote:
> no, it's not a big scalabili
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The intention was to disallow vmas starting at 0 categorically. i.e. it
>> is very intentional to deny the MREMAP_FIXED to 0 case of mremap().
>> It was also the intention to deny the MAP_FIXED to 0 case of mmap(),
>>
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> (b) sys_mremap() isn't covered.
On Thu, Jan 27, 2005 at 03:58:12PM -0500, Rik van Riel wrote:
> AFAICS it is covered.
> >--- mm1-2.6.11-rc2.orig/mm/mremap.c 2005-01-26 00:26:43.0 -0800
> >+++ mm1-2.6.11-rc2/mm
On Thu, 27 Jan 2005, William Lee Irwin III wrote:
>> The only claim above is the effect of clobbering virtual page 0 and
>> referring to this phenomenon by the macro. I was rather careful not to
>> claim a specific lower boundary to the address space.
On Thu, Jan 27, 2005 at 02:
On Thu, Jan 27, 2005 at 04:52:54AM -0800, William Lee Irwin III wrote:
>> FIRST_USER_PGD_NR is a matter of killing the entire box dead where it
>> exists, not any kind of process' preference. Userspace should be
>> prevented from setting up vmas below FIRST_USER_PGD_NR.
On
William Lee Irwin III writes:
>> There's a long discussion here, in which no one appears to have noticed
>> that SHLIB_BASE does not exist in mainline. Is anyone else awake here?
On Thu, Jan 27, 2005 at 10:29:12AM +0100, Mikael Pettersson wrote:
> About the only kernel-level
introduced by
>> cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
On Wed, Jan 26, 2005 at 10:18:57PM -0800, William Lee Irwin III wrote:
> autofs has exploded far, far beyond complete nonfunctionality, where
> in prior 2.6.x it was not quite so blatantly a doorst
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't
On Wed, Jan 26, 2005 at 09:09:27PM -0800, William Lee Irwin III wrote:
>> There's a long discussion here, in which no one appears to have noticed
>> that SHLIB_BASE does not exist in mainline. Is anyone else awake here?
On Thu, Jan 27, 2005 at 12:18:56AM -0500, Dave Jones wrot
fixes the problem in my tests.
>> Make sure that we don't allocate memory all the way down to zero,
>> so the NULL pointer never gets covered up with anonymous memory
>> and we don't end up violating the C standard.
>> Signed-off-by: Rik van Riel <[EMAIL PROTE
On Wed, Jan 26, 2005 at 11:18:08AM -0500, Rik van Riel wrote:
> With some programs the 2.6 kernel can end up allocating memory
> at address zero, for a non-MAP_FIXED mmap call! This causes
> problems with some programs and is generally rude to do. This
> simple patch fixes the problem in my tests.
On Wed, Jan 26 2005, Jens Axboe wrote:
>> Slab: 225864 kB
On Wed, Jan 26, 2005 at 09:52:30AM +0100, Jens Axboe wrote:
> The (by far) two largest slab consumers are:
> dentry_cache 140940 183060216 181 : tunables 120 60
> 0 : slabdata 10170 10170 0
> and
> ext3_in
Anton Blanchard <[EMAIL PROTECTED]> writes:
>> It is possible for one task to end up "owning" an mm from another - we
>> have seen this with the procfs code when process 1 accesses
>> /proc/pid/cmdline of process 2 while it is exiting. Process 2 exits
>> but does not tear its mm down. Later on pro
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't
wli wrote...
>> Not sure. One on kernel version being <= 2.6.10 would probably serve
>> your purposes, though it's not particularly well thought of. I suspect
>> people would suggest splitting up the codebase instead of sharing it
>> between 2.4.x and 2.6.x, where I've no idea how well that sits wi
On Mon, Jan 24, 2005 at 10:54:22AM -0600, [EMAIL PROTECTED] wrote:
> I read the messages on lkml from September 2004 about the introduction of
> remap_pfn_range and have a question related to coding for it. What do you
> recommend for driver coding to be compatible with these functions
> (remap_pag
On Fri, Jan 21, 2005 at 03:35:20PM -0800, Andrew Morton wrote:
> I am unable to find the oops trace amongst all that stuff. Help?
> (It would have been handy to include it in the bug report, actually)
There was no oops. The panic() in oom_kill.c was triggered.
-- wli
-
To unsubscribe from this
On Thu, Jan 20, 2005 at 03:17:37PM -0700, Trever L. Adams wrote:
> Second, you mentioned file systems. We were talking about ext3. I have
> never used any others in Linux (barring ext2, minixfs, and fat). I had
> heard XFS from IBM was pretty good. I would rather not use reiserfs.
XFS is from SGI.
301 - 400 of 408 matches
Mail list logo
