Bryan Wu wrote:
> On Jan 30, 2008 9:04 PM, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>> Bryan Wu wrote:
>>> From: Bernd Schmidt <[EMAIL PROTECTED]>
>>>
>>> Dont use kobjsize on the area belonging to a VMA, as it's allocated with
>>> ge
Bryan Wu wrote:
> From: Bernd Schmidt <[EMAIL PROTECTED]>
>
> Dont use kobjsize on the area belonging to a VMA, as it's allocated with
> get_free_pages.
As far as I remember, that's the case only in our tree with the patches
in nommu.c. So this patch probably should
A couple of Cc:s added.
Adrian Bunk wrote:
> On Mon, Dec 03, 2007 at 03:34:59PM -0800, Andrew Morton wrote:
>> On Sun, 2 Dec 2007 14:48:42 +0100
>> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>>
>>> On Sun, Dec 02, 2007 at 05:43:39PM +0900, Tetsuo Handa wrote:
mm/slub.c exports ksize(), but mm/slo
Adrian Bunk wrote:
> It can be a performance regression, but there are also cases where it
> can improve performance. If gcc produces lower performance code that
> would be a bug in gcc that should be reported, but using a division is
> not generally wrong.
>
> A more clearer example might be:
>
Adrian Bunk wrote:
> The gcc from svn that will become gcc 4.3 generates libgcc calls in
> cases like the following (on 32bit architectures):
>
> <-- snip -->
>
> static inline void timespec_add_ns(struct timespec *a, u64 ns)
> {
> ...
> while(ns >= NSEC_PER_SEC) {
> ns
Andrew Morton wrote:
if (rev > OLD_FLAT_VERSION) {
+ unsigned long persistent = 0;
`persistent' here only has meaning inside the next nesting level, so should
be moved down into that scope for readability reasons.
See below.
+ if (flat_set_persist
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
/dev/sdb:
0040 3fff c837 0010 003f
000
Paul Mundt wrote:
This is making API changes where it's convenient for your platform to use
this value, and there's no reason to change the API here at all.
Your proposed addition of flat_validate_relval is an API change, and
very similar in nature to what I've done.
A local variable here is t
Paul Mundt wrote:
I find it a bit disconcerting that blackfin already depends on this
in-tree without there being any earlier discussion on making these
changes.
Parts of the initial submission were picked up (the include/asm
directory), other's weren't. Little we can do about that.
Christoph Lameter wrote:
True. That is why we want to limit the number of unmovable allocations and
that is why ZONE_MOVABLE exists to limit those. However, unmovable
allocations are already rare today. The overwhelming majority of
allocations are movable and reclaimable. You can see that f.e.
Bryan Wu wrote:
This is because a binfmt_flat hacking patch for Blackfin arch is not
accept by the mainline.
Did you see someone reject it, or did it just get lost?
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Mue
Bryan Wu wrote:
but mremap doesn't -- there's even an implementation in mm/nommu.c.
Could you check the rest of these over to see if they truly don't need
to be implemented for no-mmu?
you're right we want mremap, my fault
Yes, I do think so, both sys_mremap and sys_munmap are implemented in
David Howells wrote:
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
In do_mmap_private, I've commented out the logic to free excess pages, as it
fragments terribly
I wonder if there's a good heuristic for this. The problem is that whilst
not releasing excess pages _may_ seem like
David Howells wrote:
David Howells <[EMAIL PROTECTED]> wrote:
Yes. I found the major leak this morning. There may be a minor leak, but I'm
not convinced it's in the mmap stuff. See revised patch.
Oops. That was the old patch. Try this one instead.
Here are some changes to make it more
David Howells wrote:
> Here's a preview of my patch to give each process a separate list of VMAs
> under NOMMU mode, just as under MMU mode. Could you have a look over it
> please?
I've managed to apply it to our Blackfin tree and started looking at it.
> Could you also see if you get a memory l
David Howells wrote:
> + /* we allocated a power-of-2 sized page set, so we need to trim off the
> + * excess */
> + total = 1 << order;
> + atomic_add(total, &mmap_pages_allocated);
> +
> + point = len >> PAGE_SHIFT;
> + while (point < total) {
> + order = ilo
Greg KH wrote:
On Sun, Jun 17, 2007 at 02:56:24AM -0300, Alexandre Oliva wrote:
If you want your opinions to stand a chance to make a difference, the
right place to provide them is gplv3.fsf.org/comments, and time is
running short.
[...]
So, why would we want to waste our time filling out web
Alexandre Oliva wrote:
> On Jun 17, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>> No. You've explained one thing only: that you cannot see that people don't
>> *agree* on the "spirit".
>
> They don't have to.
>
> Just like nobody but you can tell why you chose the GPLv2, nobody but
> RMS ca
Alexandre Oliva wrote:
> On Jun 16, 2007, Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>
>> Alexandre Oliva wrote:
>>> On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote:
>>>
>>>> What this means for the FSF goals if Tivo get up one morning a
Alexandre Oliva wrote:
> On Jun 15, 2007, Alan Cox <[EMAIL PROTECTED]> wrote:
>
>> What this means for the FSF goals if Tivo get up one morning and switch
>> their system firmware to ROM however is interesting 8)
>
> I'm not the FSF, and I don't speak for it, but it seems to me that
> this would
Alexandre Oliva wrote:
> On Jun 14, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote:
>
>> Tivo gets sick of the endless flamewars on lkml, signs a copy
>> of QNX, pushes it out to the hardware. No more Linux on Tivo.
>
> What do we lose?
>
> Do we actually get any benefit whatsoever from TiVO's c
Mike Frysinger wrote:
> On 6/9/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
>> On Fri, Jun 08, 2007 at 03:53:49PM +0200, Bernd Schmidt wrote:
>> > 2. It is no longer possible to get blocks smaller than a page through
>> >mmap. This behaviour was used by
ry VMA can be in two states: either it manages a power-of-2 sized compound
page, or (if VM_SPLIT_PAGES) is set, a set of single pages exactly covering
the area between vm_start and vm_end.
Signed-off-by: Bernd Schmidt <[EMAIL PROTECTED]>
fs/binfmt_elf_fdpic.c |
Linus Torvalds wrote:
>
> On Mon, 28 May 2007, Bryan Wu wrote:
>> - Blackfin arch update including BF54x initial supporting
>> - Blackfin driver update: serial/spi/rtc
>> - Provide new Blackfin watchdog driver
>> - binfmt_flat.c for Blackfin arch modification
>
> I realize that this all just
Paul Mundt wrote:
+comment "Memory Optimizations"
+
+config I_ENTRY_L1
+ bool "Locate interrupt entry code in L1 Memory"
+ default y
+ help
+ If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked
+ into L1 instruction memory.(less latency)
+
Wow, thi
On Fri, 29 Jun 2001, Alan Cox wrote:
> > Here I have to disagree with you Alan. When you pass "-march=i686" to
> > gcc, you are _not_ saying "generate code for a CPUID family 6 CPU".
> > "-march=i686" actually means "target an Intel P6 family chip, given
> > what we currently know about them". Th
On Wed, 27 Jun 2001, Alan Cox wrote:
> > The problem is that VIA Cyrix III announces itself (via CPUID)
> > as a "family 6" processor, i.e. i686 compatible. This is not
> > completely accurate, since it doesn't implement the conditional
> > move instruction. [Yeah, I know there's a CPUID feature
On Wed, 11 Apr 2001, Andreas Franck wrote:
> Hello David,
>
> > I've been discussing it with some other kernel and GCC people, and they
> > think
> > that only "memory" is required.
>
> Hmm.. I just looked at my GCC problem report from December, perhaps you're
> interested, too:
>
> http://gcc.gn
On Mon, 22 Jan 2001, Henrik Stokseth wrote:
> you were the one with the gcc 2.95.3 compiler right? even though this
> compiler is a prerelease of a stable branch i have confirmed errors in the
> optimalization passes.
Details please.
Bernd
-
To unsubscribe from this list: send the line "unsub
On Thu, 21 Dec 2000, Matthias Andree wrote:
>
> x * 10 can be written as:
>
> (x << 2 + x) << 1 = (4x+x) * 2
> (x << 3) + (x << 1) = 8x + 2x
Or as "x * 10". Which has the advantage of actually being readable, and
letting the compiler optimize it into one of the other forms if that's
profitable
On Fri, 24 Nov 2000, Tom Rini wrote:
> Well, now that there is a testcase, has anyone sent this on to the relevant
> gcc lists? (The CCs I saw haven't)
Yes. I've just sent a fix to gcc-patches.
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Tue, 17 Oct 2000, Horst von Brand wrote:
> Richard Guenther <[EMAIL PROTECTED]> said:
> > The following one is wrong, tho - should be rather
> > str[i] = dn[i]; i++;
>
> > > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
> > d/drivers/isdn/sc/deb
On Tue, 17 Oct 2000, Richard Guenther wrote:
> On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> > On Tue, 17 Oct 2000, Richard Guenther wrote:
> > > The following one is wrong, tho - should be rather
> > > str[i] = dn[i]; i++;
> >
> > Nope.
> Looking at the above code, I noticed that there are a lot of ++
> operations. I rewrote the code as:
>
> setup_from[0] = setup_from[1] = eaddrs[0];
> setup_from[2] = setup_from[3] = eaddrs[1];
> setup_from[4] = setup_from[5] = eaddrs[2];
> setup_from += 6;
>
> I compiled
On Tue, 17 Oct 2000, Helge Hafting wrote:
> Bernd Schmidt wrote:
> >
> > I've been playing with some gcc patches to detect code with undefined
> > behaviour of the i = i++ variety. The patch below fixes all places in
> > the kernel that I could find. No
On Tue, 17 Oct 2000, Richard Guenther wrote:
> On Mon, 16 Oct 2000, Bernd Schmidt wrote:
>
> > I've been playing with some gcc patches to detect code with undefined
> > behaviour of the i = i++ variety. The patch below fixes all places in
> > the kernel that I c
On Mon, 16 Oct 2000, Jeff Garzik wrote:
> > --- linux-2.4/drivers/scsi/aha152x.cMon Oct 16 13:51:24 2000
> > +++ linux-2.4-fixed/drivers/scsi/aha152x.c Mon Oct 16 14:51:29 2000
> > @@ -1280,7 +1280,8 @@
> > scsi_unregister(shpnt);
> > regis
I've been playing with some gcc patches to detect code with undefined
behaviour of the i = i++ variety. The patch below fixes all places in
the kernel that I could find. Note that in some cases, it wasn't
entirely clear what the code intended, so I had to guess.
I haven't tested this patch at a
38 matches
Mail list logo
