Al Viro wrote:
> On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
> > The real (but harder) fix for the wasted space issue
> > would be to get the toolchain to automatically combine functions that
> > end up compiling into identical assembly.
>
>
Linus Torvalds wrote:
> Well, that probably would work, but it's also true that returning a 64-bit
> value on a 32-bit platform really _does_ depend on more than the size.
Yeah, obviously this is restricted to the signed-integer case. My point
was just that you could have the compiler figure
Al Viro wrote:
> At least 3 versions, unless you want to mess with ifdefs to reduce them to
> two.
I don't think you need to do fancy #ifdef's:
static s32 return_eio_32(void) { return -EIO; }
static s64 return_eio_64(void) { return -EIO; }
extern void return_eio_unknown(void); /* Doesn't exist
Al Viro wrote:
At least 3 versions, unless you want to mess with ifdefs to reduce them to
two.
I don't think you need to do fancy #ifdef's:
static s32 return_eio_32(void) { return -EIO; }
static s64 return_eio_64(void) { return -EIO; }
extern void return_eio_unknown(void); /* Doesn't exist
Linus Torvalds wrote:
Well, that probably would work, but it's also true that returning a 64-bit
value on a 32-bit platform really _does_ depend on more than the size.
Yeah, obviously this is restricted to the signed-integer case. My point
was just that you could have the compiler figure out
Al Viro wrote:
On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
The real (but harder) fix for the wasted space issue
would be to get the toolchain to automatically combine functions that
end up compiling into identical assembly.
Can't do.
[...]
Comparing pointers
CH] [ATM] remove firestream.c's aligned_kmalloc()
Signed-off-by: Mitchell Blank Jr <[EMAIL PROTECTED]>
diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
index 9c67df5..df8b0c0 100644
--- a/drivers/atm/firestream.c
+++ b/drivers/atm/firestream.c
@@ -1379,38 +1379,22 @@ static void reset_
aligned_kmalloc()
Signed-off-by: Mitchell Blank Jr [EMAIL PROTECTED]
diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
index 9c67df5..df8b0c0 100644
--- a/drivers/atm/firestream.c
+++ b/drivers/atm/firestream.c
@@ -1379,38 +1379,22 @@ static void reset_chip (struct fs_dev *d
Andi Kleen wrote:
> - it doesn't seem to help that much on modern CPUs with good
> branch prediction and big icaches anyways.
Really? I would think that as pipelines get deeper (although that trend
seems to have stopped, thankfully) and Icache-miss penalties get relatively
larger we'd see
Richard Henderson wrote:
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int
Andi Kleen wrote:
- it doesn't seem to help that much on modern CPUs with good
branch prediction and big icaches anyways.
Really? I would think that as pipelines get deeper (although that trend
seems to have stopped, thankfully) and Icache-miss penalties get relatively
larger we'd see
Richard Henderson wrote:
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int
Still one nitpick:
Jon Smirl wrote:
> + while (isspace(*x) && (x - buffer->page < count))
> + x++;
I think you can just do:
if (count > 0)
while (isspace(*x))
x++;
If the passed-in string was fully whitespace then the
Jon Smirl wrote:
> Do we need to deal with UTF8 here? I did the forward loop because you
> can't parse UTF8 backwards. If UTF8 is possible I need to change the
> pointer inc function.
As others have mentioned there shouldn't be a UTF8 problem with isspace().
However, even if you wanted to scan
Steven Rostedt wrote:
> In the thread "[RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO
> configurable" I discovered that a C version of find_first_bit is faster
> than the asm version
There are probably other cases of this in asm-i386/bitopts.h. For instance
I think the "btl" instruction is
Greg KH wrote:
> > + /* locate trailng white space */
> > + z = y = x;
> > + while (y - buffer->page < count) {
> > + y++;
> > + z = y;
> > + while (isspace(*y) && (y - buffer->page < count)) {
> > + y++;
> > + }
> > + }
> > +
Greg KH wrote:
+ /* locate trailng white space */
+ z = y = x;
+ while (y - buffer-page count) {
+ y++;
+ z = y;
+ while (isspace(*y) (y - buffer-page count)) {
+ y++;
+ }
+ }
+ count = z - x;
Hm, I
Steven Rostedt wrote:
In the thread [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO
configurable I discovered that a C version of find_first_bit is faster
than the asm version
There are probably other cases of this in asm-i386/bitopts.h. For instance
I think the btl instruction is pretty
Jon Smirl wrote:
Do we need to deal with UTF8 here? I did the forward loop because you
can't parse UTF8 backwards. If UTF8 is possible I need to change the
pointer inc function.
As others have mentioned there shouldn't be a UTF8 problem with isspace().
However, even if you wanted to scan going
Still one nitpick:
Jon Smirl wrote:
+ while (isspace(*x) (x - buffer-page count))
+ x++;
I think you can just do:
if (count 0)
while (isspace(*x))
x++;
If the passed-in string was fully whitespace then the trailing-whitespace
Ted Kremenek wrote:
> Currently we are looking primarily into the
> ioctls in drivers/net,
Just as a small aside, a little over five years ago (wow does time fly!) I
did a manual audit for mistakes like this:
http://lkml.org/lkml/2000/3/7/156
Not sure if that's relevant to your work your
Ted Kremenek wrote:
Currently we are looking primarily into the
ioctls in drivers/net,
Just as a small aside, a little over five years ago (wow does time fly!) I
did a manual audit for mistakes like this:
http://lkml.org/lkml/2000/3/7/156
Not sure if that's relevant to your work your
Stephen C. Tweedie wrote:
> If we want to fix this, let's fix the macros: for example, convert
> EXT3_HAS_COMPAT_FEATURE to be
>
> ( le32_to_cpu(EXT3_SB(sb)->s_es->s_feature_compat) & (mask) )
Of course that's less efficient though since "mask" is probably constant..
so now the endian
Stephen C. Tweedie wrote:
If we want to fix this, let's fix the macros: for example, convert
EXT3_HAS_COMPAT_FEATURE to be
( le32_to_cpu(EXT3_SB(sb)-s_es-s_feature_compat) (mask) )
Of course that's less efficient though since mask is probably constant..
so now the endian conversion
[EMAIL PROTECTED] wrote:
> SUBJECT:
> Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
>
>
> DRIVER RESULTS:
> Works fine in 2.4.0 kernel.
> Locks up system (no messages/oops/etc.) in 2.4.2-2 kernel (rh 7.1).
> Locks up system (no messages/oops/etc.) in 2.4.2 kernel (w/ or w/o kgdb).
>
[EMAIL PROTECTED] wrote:
SUBJECT:
Lockup in 2.4.2 kernel ADSL PCI card ATM driver module
DRIVER RESULTS:
Works fine in 2.4.0 kernel.
Locks up system (no messages/oops/etc.) in 2.4.2-2 kernel (rh 7.1).
Locks up system (no messages/oops/etc.) in 2.4.2 kernel (w/ or w/o kgdb).
Locks up
Alexander Viro wrote:
> I can see how to implement per-mountpoint variant. However, I'm
> less than enthusiastic about the API side of that and about the
> ugliness it will lead to. It smells like a wrong approach. And
> no, I don't see a good one right now.
Aren't we one day going to have
Alexander Viro wrote:
I can see how to implement per-mountpoint variant. However, I'm
less than enthusiastic about the API side of that and about the
ugliness it will lead to. It smells like a wrong approach. And
no, I don't see a good one right now.
Aren't we one day going to have stackable
Wichert Akkerman wrote:
> You are just delaying the problem then, at some point your uptime will
> be large enough that you have run through all 64bit pids for example.
64 bits is enough to fork 1 million processes per second for over
500,000 years. I think that's putting the problem off far
Wichert Akkerman wrote:
You are just delaying the problem then, at some point your uptime will
be large enough that you have run through all 64bit pids for example.
64 bits is enough to fork 1 million processes per second for over
500,000 years. I think that's putting the problem off far
Andreas Dilger wrote:
> With per-group (or maybe per-bitmap) locking, files could be created in
> parallel with only a small amount of global locking if they are in different
> groups.
...and then we can let the disc go nuts seeking to actually commit all
these new blocks. I suspect that this
Andreas Dilger wrote:
With per-group (or maybe per-bitmap) locking, files could be created in
parallel with only a small amount of global locking if they are in different
groups.
...and then we can let the disc go nuts seeking to actually commit all
these new blocks. I suspect that this
Junfeng Yang wrote:
> [BUG] fore200e_kmalloc can return NULL
> /u2/acc/oses/linux/2.4.1/drivers/atm/fore200e.c:2032:fore200e_get_esi:
>ERROR:NULL:2020:2032: Using unknown ptr "prom" illegally! set by
>'fore200e_kmalloc':2020
I don't see the bug - there is an explicit "if(!prom) return
Junfeng Yang wrote:
[BUG] fore200e_kmalloc can return NULL
/u2/acc/oses/linux/2.4.1/drivers/atm/fore200e.c:2032:fore200e_get_esi:
ERROR:NULL:2020:2032: Using unknown ptr "prom" illegally! set by
'fore200e_kmalloc':2020
I don't see the bug - there is an explicit "if(!prom) return -ENOMEM;"
Miguel Armas wrote:
> A couple days ago we installed a Fore 200E ATM card and after getting the
> ATM address using ilmid the machine hangs. The kernel still respond to
> pings, but the userspace is dead.
>
> If we remove SMP support in the kernel everything works fine (but with
> only one
David S. Miller wrote:
> - hash = hash ^ (hash >> D_HASHBITS) ^ (hash >> D_HASHBITS*2);
> + hash = hash ^ (hash >> D_HASHBITS) ^
> + (hash >> (D_HASHBITS+(D_HASHBITS/2)));
Two comments:
1. The inode-cache has the exact same problem, but it'll require a lot
of RAM to
David S. Miller wrote:
- hash = hash ^ (hash D_HASHBITS) ^ (hash D_HASHBITS*2);
+ hash = hash ^ (hash D_HASHBITS) ^
+ (hash (D_HASHBITS+(D_HASHBITS/2)));
Two comments:
1. The inode-cache has the exact same problem, but it'll require a lot
of RAM to run into it.
Ingo Molnar wrote:
> - probably the most radical solution is what i suggested, to completely
> avoid the unique-mapping of file structures to an integer range, and use
> the address of the file structure (and some cookies) as an identification.
IMO... gross. We do pretty much this exact thing
Ingo Molnar wrote:
- probably the most radical solution is what i suggested, to completely
avoid the unique-mapping of file structures to an integer range, and use
the address of the file structure (and some cookies) as an identification.
IMO... gross. We do pretty much this exact thing in
H. Peter Anvin wrote:
> I suggested include/kernel and include/arch with include/linux and
> include/asm being reserved for the kernel interfaces (ioctl and their
> structures mostly.)
That sounds good. One other refinement I would like to see is that
architecture specific but always present
First, I'd like to make a couple points about driver style that I'm trying
to move towards with the ATM drivers. You're free to take them or leave
them, but I want to eventually move the tree in this direction.
* I don't like header files that define the registers of the chip - since
the
Patrick van de Lageweg wrote:
> This patch contains the fix for the atmrefcount problem (noted as a
> critical problem in Ted's todo list). It also has the makefile
> modifications for the firestream driver in a separate email.
Could you please split the two patches so that they're actually
Patrick van de Lageweg wrote:
This patch contains the fix for the atmrefcount problem (noted as a
critical problem in Ted's todo list). It also has the makefile
modifications for the firestream driver in a separate email.
Could you please split the two patches so that they're actually
First, I'd like to make a couple points about driver style that I'm trying
to move towards with the ATM drivers. You're free to take them or leave
them, but I want to eventually move the tree in this direction.
* I don't like header files that define the registers of the chip - since
the
H. Peter Anvin wrote:
I suggested include/kernel and include/arch with include/linux and
include/asm being reserved for the kernel interfaces (ioctl and their
structures mostly.)
That sounds good. One other refinement I would like to see is that
architecture specific but always present
Richard B. Johnson wrote:
> > And here is the broken routine:
> >
> > 03f4 :
[...]
> This is not good code. It does the following:
>
> o Gets a parameter off the stack and puts into eax (a pointer).
> o Put the value 1 into ecx.
> o Take a byte from the pointed-to location and
Richard B. Johnson wrote:
And here is the broken routine:
03f4 do_test_wp_bit:
[...]
This is not good code. It does the following:
o Gets a parameter off the stack and puts into eax (a pointer).
o Put the value 1 into ecx.
o Take a byte from the pointed-to location
Linus Torvalds wrote:
> > * it doesn't add extra syscalls
>
> Sure it does.
>
> What do you think ioctl's are?
As I explained a few lines down from where you stopped quoting (and probably
stopped reading) the ioctl() use is just an artifact of Solaris's icky
implementation. It could and
Linus Torvalds wrote:
> Here's a suggested "good" interface that would certainly be easy to
> implement, and very easy to use, with none of the scalability issues that
> many interfaces have.
I think everyone should take a timeout and look at Solaris 8's /dev/poll
interface. This discussion is
Linus Torvalds wrote:
Here's a suggested "good" interface that would certainly be easy to
implement, and very easy to use, with none of the scalability issues that
many interfaces have.
I think everyone should take a timeout and look at Solaris 8's /dev/poll
interface. This discussion is
Linus Torvalds wrote:
* it doesn't add extra syscalls
Sure it does.
What do you think ioctl's are?
As I explained a few lines down from where you stopped quoting (and probably
stopped reading) the ioctl() use is just an artifact of Solaris's icky
implementation. It could and should
Jason Slagle wrote:
> It worked fine under 2.3.x and as a matter of fact worked fine under
> 2.4.0-test1-4 I believe.
>
> I don't buy a hardware explination when I've been running this setup for
> well over a year and only just now have problems :)
It's because we've seen it a hundred zillion
Jason Slagle wrote:
It worked fine under 2.3.x and as a matter of fact worked fine under
2.4.0-test1-4 I believe.
I don't buy a hardware explination when I've been running this setup for
well over a year and only just now have problems :)
It's because we've seen it a hundred zillion times
Werner Almesberger wrote:
> Mitchell Blank Jr wrote:
> > Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc
> > open/close) code is pretty suspect.
>
> That's actually a bit of an understatement:
Well, I was trying to be polite to the origin
Rogier Wolff wrote:
> We're trying to make the module refcounting 'secure' against
> concurrent SMP unloads.
>
> For example in net/atm/resources.c:
Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc
open/close) code is pretty suspect. If you want to look through and
Werner Almesberger wrote:
Mitchell Blank Jr wrote:
Yeah, a lot of the add/remove device ATM code (and, IMO, even the vcc
open/close) code is pretty suspect.
That's actually a bit of an understatement:
Well, I was trying to be polite to the original author ;-)
-Mitch
-
To unsubscribe
[EMAIL PROTECTED] wrote:
> 4. Boot Time Failures
[...]
> * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
>more info)
I _highly_ suspect that this is not a 2.4 bug but is instead user error.
I've seen it several times.
On all kernel versions prior to 2.3.11 if you
[EMAIL PROTECTED] wrote:
4. Boot Time Failures
[...]
* IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
more info)
I _highly_ suspect that this is not a 2.4 bug but is instead user error.
I've seen it several times.
On all kernel versions prior to 2.3.11 if you
Dan Aloni wrote:
>
> I've been touring around the kernel sources when I stumbled
> across the uid_hash_find() function (kernel/user.c):
>
> static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
>hashent)
Is it just me, or should that be "uid_t" not "unsigned short"?
[EMAIL PROTECTED] wrote:
> > Yes, on architectures that use current->processor that is an exception
> > to the rule. After all, you know for sure that you're still on the
> > same CPU as the task currently running.
>
> This makes sense. And I wish cpu architects would put a cpu-id
> register
[EMAIL PROTECTED] wrote:
> Looking at the code, I don't see any places where "current" is not valid.
> Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is
[EMAIL PROTECTED] wrote:
Looking at the code, I don't see any places where "current" is not valid.
Got some examples?
It's not that its invalid, it just doesn't make much sense. It points to
whatever task happened to be running when the interrupt happened. So
any attempt to access it is 99%
[EMAIL PROTECTED] wrote:
Yes, on architectures that use current-processor that is an exception
to the rule. After all, you know for sure that you're still on the
same CPU as the task currently running.
This makes sense. And I wish cpu architects would put a cpu-id
register somewhere
Dan Aloni wrote:
I've been touring around the kernel sources when I stumbled
across the uid_hash_find() function (kernel/user.c):
static inline struct user_struct *uid_hash_find(unsigned short uid, unsigned int
hashent)
Is it just me, or should that be "uid_t" not "unsigned short"? Now
James Sutherland wrote:
> In terms of latency, I'd suggest we aim to keep the device in use all the
> time we have outstanding requests: every time the device is ready to
> accept a request, we feed it the "next" one in the queue; until it is free
> again, requests pile up in the queue, being
Alexander Viro wrote:
> BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
> " will be cheerfully flushed down the toilet here,
> no matter what system of dependencies is going to be in place.
Yes, for the stuff discussed on lkml patch dependencies should be
pretty minimal.
Alan Cox wrote:
> Humans will generally get a weird report from sending Linus a message wonder
> what all this field stuff is and mail someone else instead.
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've seen some pretty dim folks manage
Alan Cox wrote:
> > Yes, but "how hard is it reasonable for the kernel to try" is based on
> > both items. A good first order approximation is number of requests.
>
> I must strongly disagree with that claim. A request could be 512 bytes or
> 128K.
Yeah, as sct pointed out this gets thorny.
Daniel Quinlan wrote:
> "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
> The web page will list valid version strings.
Ideally this should be overridable for patches marked experimental, since
they might be to some modified kernel. Of course you
Daniel Quinlan wrote:
"Version" - the base kernel version. For example, "2.4.0-test8-pre1".
The web page will list valid version strings.
Ideally this should be overridable for patches marked experimental, since
they might be to some modified kernel. Of course you
Alan Cox wrote:
Humans will generally get a weird report from sending Linus a message wonder
what all this field stuff is and mail someone else instead.
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've seen some pretty dim folks manage
Alexander Viro wrote:
BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
long list of patches" will be cheerfully flushed down the toilet here,
no matter what system of dependencies is going to be in place.
Yes, for the stuff discussed on lkml patch dependencies should be
James Sutherland wrote:
In terms of latency, I'd suggest we aim to keep the device in use all the
time we have outstanding requests: every time the device is ready to
accept a request, we feed it the "next" one in the queue; until it is free
again, requests pile up in the queue, being sorted,
Alan Cox wrote:
> > time, but remember that there are two things measured in time here:
> > A. The time for the whole queue of requests to run (this is what Rik is
> > proposing using to throttle)
> > B. The time an average request takes to process.
>
> Your perceived latency is based
Alan Cox wrote:
> > Now, I see people trying to introduce the concept of elapsed time into
> > that fix, which smells strongly of hack. How will this hack be cobbled
>
> Actually my brain says that elapsed time based scheduling is the right thing
> to do.
No, Andrea is right here. The argument
Alan Cox wrote:
Now, I see people trying to introduce the concept of elapsed time into
that fix, which smells strongly of hack. How will this hack be cobbled
Actually my brain says that elapsed time based scheduling is the right thing
to do.
No, Andrea is right here. The argument that
Alan Cox wrote:
time, but remember that there are two things measured in time here:
A. The time for the whole queue of requests to run (this is what Rik is
proposing using to throttle)
B. The time an average request takes to process.
Your perceived latency is based entirely on
77 matches
Mail list logo
