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
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
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);
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/debug.c
---
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
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 the
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 flag for
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:
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, this
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
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
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.
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.
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
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 -=
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:
--
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/slob.c and
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
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
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:
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 a good idea
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 = ilog2(total -
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 leak
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. The gcc info
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 shouldn't go upstream yet.
Bernd
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
get_free_pages.
As far as I remember, that's the case only in our tree
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 | 17 +-
fs/binfmt_flat.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 simplemalloc, which is an insane
way
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 choice of
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 be mission
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 and switch
their system firmware to ROM however is interesting 8)
I'm
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 can tell why he
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
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 touches
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
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 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".
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
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
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);
> >
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 could
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. Note th
> 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, 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.
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
> >
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
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:
>
>
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,
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
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 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 mornin
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
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 | 17 +-
fs/binfmt_
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
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
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
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
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 a goo
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, _pages_allocated);
> +
> + point = len >> PAGE_SHIFT;
> + while (point < total) {
> + order =
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
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
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
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
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
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.
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.
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
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) {
>
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:
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
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 shouldn't go ups
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
>>> get_
72 matches
Mail list logo
