On 4/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Basically this hack is bad on policy grounds because it is giving X an
"legislated, unfair monopoly" on the system. It's the equivalent of a
state-guaranteed monopoly in certain 'strategic industries'. It has some
advantages but it is very much
On 4/23/07, Ingo Molnar [EMAIL PROTECTED] wrote:
Basically this hack is bad on policy grounds because it is giving X an
legislated, unfair monopoly on the system. It's the equivalent of a
state-guaranteed monopoly in certain 'strategic industries'. It has some
advantages but it is very much net
On 4/19/07, hui Bill Huey <[EMAIL PROTECTED]> wrote:
DSP operations like, particularly with digital synthesis, tend to max
the CPU doing vector operations on as many processors as it can get
a hold of. In a live performance critical application, it's important
to be able to deliver a protected
On 4/19/07, hui Bill Huey [EMAIL PROTECTED] wrote:
DSP operations like, particularly with digital synthesis, tend to max
the CPU doing vector operations on as many processors as it can get
a hold of. In a live performance critical application, it's important
to be able to deliver a protected
On 4/19/07, Lee Revell <[EMAIL PROTECTED]> wrote:
IMHO audio streamers should use SCHED_FIFO thread for time critical
work. I think it's insane to expect the scheduler to figure out that
these processes need low latency when they can just be explicit about
it. "Professional" audio software
On 4/19/07, Alan Cox <[EMAIL PROTECTED]> wrote:
The troll is back I see.
Troll, shmoll. I call 'em like I see 'em. As much as I like and
depend on Linux, and as much as I respect the contributions and the
ideals of the EXPORT_SYMBOL_GPL partisans, they're spreading needless
FUD by spraying
On 4/19/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
The cpu scheduler core is a cpu bandwidth and latency
proportionator and should be nothing more or less.
Not really. The CPU scheduler is (or ought to be) what electric
utilities call an economic dispatch mechanism -- a real-time
controller
On 4/19/07, Chris Bergeron <[EMAIL PROTECTED]> wrote:
It just seemed like it might be interesting and I couldn't find anything
to shed light on the error itself in the mailing list logs, and I'm
curious at what's happening.
What's happening is that some kernel developers don't like Linus's
On 4/19/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
Having tried re-nicing X a while back, and having the rest of the system
suffer in quite obvious ways for even 1 + or - from its default felt pretty
bad from this users perspective.
It is my considered opinion (yeah I know, I'm just a leaf in
On 4/19/07, Gene Heskett [EMAIL PROTECTED] wrote:
Having tried re-nicing X a while back, and having the rest of the system
suffer in quite obvious ways for even 1 + or - from its default felt pretty
bad from this users perspective.
It is my considered opinion (yeah I know, I'm just a leaf in
On 4/19/07, Chris Bergeron [EMAIL PROTECTED] wrote:
It just seemed like it might be interesting and I couldn't find anything
to shed light on the error itself in the mailing list logs, and I'm
curious at what's happening.
What's happening is that some kernel developers don't like Linus's
On 4/19/07, Con Kolivas [EMAIL PROTECTED] wrote:
The cpu scheduler core is a cpu bandwidth and latency
proportionator and should be nothing more or less.
Not really. The CPU scheduler is (or ought to be) what electric
utilities call an economic dispatch mechanism -- a real-time
controller
On 4/19/07, Alan Cox [EMAIL PROTECTED] wrote:
The troll is back I see.
Troll, shmoll. I call 'em like I see 'em. As much as I like and
depend on Linux, and as much as I respect the contributions and the
ideals of the EXPORT_SYMBOL_GPL partisans, they're spreading needless
FUD by spraying
On 4/19/07, Lee Revell [EMAIL PROTECTED] wrote:
IMHO audio streamers should use SCHED_FIFO thread for time critical
work. I think it's insane to expect the scheduler to figure out that
these processes need low latency when they can just be explicit about
it. Professional audio software does it
On 4/18/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
For the record, you actually don't need to track a whole NxN matrix
(or do the implied O(n**3) matrix inversion!) to get to the same
result. You can converge on the same node weightings (ie dynamic
priorities) by applying a damped function at
On 4/18/07, Matt Mackall [EMAIL PROTECTED] wrote:
For the record, you actually don't need to track a whole NxN matrix
(or do the implied O(n**3) matrix inversion!) to get to the same
result. You can converge on the same node weightings (ie dynamic
priorities) by applying a damped function at
On 4/17/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
The ongoing scheduler work is on a much more basic level than these
affairs I'm guessing you googled. When the basics work as intended it
will be possible to move on to more advanced issues.
OK, let me try this in smaller words for
On 4/17/07, Peter Williams <[EMAIL PROTECTED]> wrote:
The other way in which the code deviates from the original as that (for
a few years now) I no longer calculated CPU bandwidth usage directly.
I've found that the overhead is less if I keep a running average of the
size of a tasks CPU bursts
On 4/17/07, Peter Williams [EMAIL PROTECTED] wrote:
The other way in which the code deviates from the original as that (for
a few years now) I no longer calculated CPU bandwidth usage directly.
I've found that the overhead is less if I keep a running average of the
size of a tasks CPU bursts and
On 4/17/07, William Lee Irwin III [EMAIL PROTECTED] wrote:
The ongoing scheduler work is on a much more basic level than these
affairs I'm guessing you googled. When the basics work as intended it
will be possible to move on to more advanced issues.
OK, let me try this in smaller words for
On 4/16/07, Peter Williams <[EMAIL PROTECTED]> wrote:
Note that I talk of run queues
not CPUs as I think a shift to multiple CPUs per run queue may be a good
idea.
This observation of Peter's is the best thing to come out of this
whole foofaraw. Looking at what's happening in CPU-land, I
On 4/16/07, Peter Williams [EMAIL PROTECTED] wrote:
Note that I talk of run queues
not CPUs as I think a shift to multiple CPUs per run queue may be a good
idea.
This observation of Peter's is the best thing to come out of this
whole foofaraw. Looking at what's happening in CPU-land, I think
do_acct_process (in kernel/acct.c) bypasses vfs_write and calls
file->f_op->write directly. It therefore bypasses various sanity
checks, some of which appear applicable (notably inode->i_flock &&
MANDATORY_LOCK(inode)) and others of which do not (oversize request,
access_ok, etc.). It also
Thanks Alan, this is really helpful -- I'll see if I can figure out
kprobes. It is not immediately obvious to me how to use them to trace
function calls in userspace, but I'll read up.
On 3/13/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> But on that note -- do you have any idea how one might get
It appears that there are (at least) two ways to get the inode (if
any) associated with an open file: f_mapping->host (pagecache?) and
f_path.dentry->d_inode (dentry cache?). generic_file_llseek uses
f_mapping->host; everything else in read_write.c uses
f_path.dentry->d_inode. do_sendfile
It appears that there are (at least) two ways to get the inode (if
any) associated with an open file: f_mapping-host (pagecache?) and
f_path.dentry-d_inode (dentry cache?). generic_file_llseek uses
f_mapping-host; everything else in read_write.c uses
f_path.dentry-d_inode. do_sendfile checks
Thanks Alan, this is really helpful -- I'll see if I can figure out
kprobes. It is not immediately obvious to me how to use them to trace
function calls in userspace, but I'll read up.
On 3/13/07, Alan Cox [EMAIL PROTECTED] wrote:
But on that note -- do you have any idea how one might get
do_acct_process (in kernel/acct.c) bypasses vfs_write and calls
file-f_op-write directly. It therefore bypasses various sanity
checks, some of which appear applicable (notably inode-i_flock
MANDATORY_LOCK(inode)) and others of which do not (oversize request,
access_ok, etc.). It also neglects
In case anyone cares, this is a snippet of my work-in-progress
read_write.c illustrating how I might handle f_pos. Can anyone point
me to data showing whether it's worth avoiding the spinlock when the
"struct file" is not shared between threads? (In my world,
correctness comes before
On 3/13/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Thank you Christoph for that
Clearly f_pos atomicity has been handled differently in the not-so-distant past:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html
And equally clearly the current generic_file_llseek semantics are
erroneous for large offsets, and we shouldn't be taking the inode
mutex in
On 3/13/07, David Miller <[EMAIL PROTECTED]> wrote:
You're not even safe over standard output, simply run the program over
ssh and you suddenly have socket semantics to deal with.
I'm intimately familiar with this one. Easily worked around by piping
the output through cat or tee. Not that
On 3/12/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> Writing to a file from multiple processes is not usually the problem.
> Writing to a common "struct file" from multiple threads is.
Not normally because POSIX sensibly invented pread/pwrite. Forgot
preadv/pwritev but they did the basics and end
On 3/12/07, Alan Cox [EMAIL PROTECTED] wrote:
Writing to a file from multiple processes is not usually the problem.
Writing to a common struct file from multiple threads is.
Not normally because POSIX sensibly invented pread/pwrite. Forgot
preadv/pwritev but they did the basics and end of
On 3/13/07, David Miller [EMAIL PROTECTED] wrote:
You're not even safe over standard output, simply run the program over
ssh and you suddenly have socket semantics to deal with.
I'm intimately familiar with this one. Easily worked around by piping
the output through cat or tee. Not that one
Clearly f_pos atomicity has been handled differently in the not-so-distant past:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg01628.html
And equally clearly the current generic_file_llseek semantics are
erroneous for large offsets, and we shouldn't be taking the inode
mutex in
On 3/13/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
Michael, please stop spreading this utter bullshit _now_. You're so
full of half-knowledge that it's not funny anymore, and you try
to insult people knowing a few magniutes more than you left and right.
Thank you Christoph for that
In case anyone cares, this is a snippet of my work-in-progress
read_write.c illustrating how I might handle f_pos. Can anyone point
me to data showing whether it's worth avoiding the spinlock when the
struct file is not shared between threads? (In my world,
correctness comes before code-bumming
On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
> That's fine when you're doing integration test, and should probably be
> the default during development. But if the race is first exposed in
> the field, or if the deve
On 3/12/07, Bodo Eggert <[EMAIL PROTECTED]> wrote:
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before the vfs_write() call.
This is a security risk.
other process:
unlink(secre
On 3/12/07, Bodo Eggert [EMAIL PROTECTED] wrote:
Michael K. Edwards [EMAIL PROTECTED] wrote:
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call.
This is a security risk.
other process:
unlink(secrest_file)
Thread 1
On 3/12/07, Bodo Eggert [EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007, Michael K. Edwards wrote:
That's fine when you're doing integration test, and should probably be
the default during development. But if the race is first exposed in
the field, or if the developer is trying to concentrate
I apologize for throwing around words like "stupid". Whether or not
the current semantics can be improved, that's not a constructive way
to characterize them. I'm sorry.
As three people have ably pointed out :-), the particular case of a
pipe/FIFO isn't seekable and doesn't need the f_pos
On 3/8/07, Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
Any number of things can cause a short write to occur, and rewinding the
file position after the fact is just as bad. A sane app has to either
serialise the writes itself or use a thread safe API like pwrite().
Not on a pipe/FIFO. Short
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Dont even try, you *cannot* do that, without breaking the standards, or
without a performance drop.
The only safe way would be to lock the file during the whole read()/write()
syscall, and we dont want this (this would be more expensive than
On 3/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Dont even try, you *cannot* do that, without breaking the standards, or
without a performance drop.
The only safe way would be to lock the file during the whole read()/write()
syscall, and we dont want this (this would be more expensive than
On 3/8/07, Benjamin LaHaise [EMAIL PROTECTED] wrote:
Any number of things can cause a short write to occur, and rewinding the
file position after the fact is just as bad. A sane app has to either
serialise the writes itself or use a thread safe API like pwrite().
Not on a pipe/FIFO. Short
I apologize for throwing around words like stupid. Whether or not
the current semantics can be improved, that's not a constructive way
to characterize them. I'm sorry.
As three people have ably pointed out :-), the particular case of a
pipe/FIFO isn't seekable and doesn't need the f_pos member
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unless fget_light sets fput_needed
On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Nothing in the manuals says that write() on same fd should be non racy : In
particular file pos might be undefined. There is a reason pwrite() exists.
Kernel doesnt have to enforce thread safety as standard is quite clear.
I know the standard
from sys_write():
file = fget_light(fd, _needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_write(file, buf, count, );
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
Surely that's racy
On 3/8/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
So anybody who would "go with the Berkeley crowd" really shows a lot of
bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's
so long ago that I don't think there is any point in us trying to fix it
any more.
Well, they
On 3/8/07, Davide Libenzi wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex structures over it, it
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
No, I just checked, and Intel's own optimization manual makes it clear
that you should be careful. They talk about performance penalties due to
resource constraints - which makes tons of sense with a core that is good
at handling its own
On 3/8/07, Davide Libenzi davidel@xmailserver.org wrote:
The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex
On 3/8/07, Linus Torvalds [EMAIL PROTECTED] wrote:
So anybody who would go with the Berkeley crowd really shows a lot of
bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's
so long ago that I don't think there is any point in us trying to fix it
any more.
Well, they did
from sys_write():
file = fget_light(fd, fput_needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_write(file, buf, count, pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
Surely that's
On 3/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Nothing in the manuals says that write() on same fd should be non racy : In
particular file pos might be undefined. There is a reason pwrite() exists.
Kernel doesnt have to enforce thread safety as standard is quite clear.
I know the standard
On 3/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the vfs_write() call. Unless fget_light sets fput_needed
or
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote:
No, I just checked, and Intel's own optimization manual makes it clear
that you should be careful. They talk about performance penalties due to
resource constraints - which makes tons of sense with a core that is good
at handling its own
I wrote:
I didn't see any clean way to intersperse overwrites and appends to a
record-structured file without using vfs_llseek, which steps on f_pos.
The context, of course, is an attempt to fix -ENOPATCH with regard to
the netlink-based AIO submission scheme I outlined a couple of days
ago.
On 3/7/07, Alan Cox <[EMAIL PROTECTED]> wrote:
The right way IMHO would be to do the work that was done for pread/pwrite
and implement preadv/pwritev. The moment you want to do atomic things
with the file->f_pos instead of doing it with a local passed pos value it
gets ugly.. why do you need to
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote
Yeah, I'm not at all surprised. Any implementation of "prefetch" that
doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
them weaker for *actual* prefetching) will generally have a hard time with
a NULL pointer. Exactly
Suppose I want to create an atomic llseek+writev operation. Is this
more or less sufficient:
ssize_t ret = -EBADF;
file = fget_light(fd, _needed);
if (file) {
if (unlikely(origin > 2)) {
ret = -EINVAL;
} else {
Suppose I want to create an atomic llseek+writev operation. Is this
more or less sufficient:
ssize_t ret = -EBADF;
file = fget_light(fd, fput_needed);
if (file) {
if (unlikely(origin 2)) {
ret = -EINVAL;
} else {
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote
Yeah, I'm not at all surprised. Any implementation of prefetch that
doesn't just turn into a no-op if the TLB entry doesn't exist (which makes
them weaker for *actual* prefetching) will generally have a hard time with
a NULL pointer. Exactly
On 3/7/07, Alan Cox [EMAIL PROTECTED] wrote:
The right way IMHO would be to do the work that was done for pread/pwrite
and implement preadv/pwritev. The moment you want to do atomic things
with the file-f_pos instead of doing it with a local passed pos value it
gets ugly.. why do you need to do
I wrote:
I didn't see any clean way to intersperse overwrites and appends to a
record-structured file without using vfs_llseek, which steps on f_pos.
The context, of course, is an attempt to fix -ENOPATCH with regard to
the netlink-based AIO submission scheme I outlined a couple of days
ago.
On 3/4/07, Kyle Moffett <[EMAIL PROTECTED]> wrote:
Well, even this far into 2.6, Linus' patch from 2003 still (mostly)
applies; the maintenance cost for this kind of code is virtually
zilch. If it matters that much to you clean it up and make it apply;
add an alarmfd() syscall (another 100
Please don't take this the wrong way, Ray, but I don't think _you_
understand the problem space that people are (or should be) trying to
address here.
Servers want to always, always block. Not on a socket, not on a stat,
not on any _one_ thing, but in a condition where the optimum number of
Please don't take this the wrong way, Ray, but I don't think _you_
understand the problem space that people are (or should be) trying to
address here.
Servers want to always, always block. Not on a socket, not on a stat,
not on any _one_ thing, but in a condition where the optimum number of
On 3/4/07, Kyle Moffett [EMAIL PROTECTED] wrote:
Well, even this far into 2.6, Linus' patch from 2003 still (mostly)
applies; the maintenance cost for this kind of code is virtually
zilch. If it matters that much to you clean it up and make it apply;
add an alarmfd() syscall (another 100 lines
On 3/2/07, Davide Libenzi wrote:
For threadlets, it might be. Now think about a task wanting to dispatch N
parallel AIO requests as N independent syslets.
Think about this task having USEDFPU set, so the FPU context is dirty.
When it returns from async_exec, with one of the requests being
On 3/2/07, Davide Libenzi davidel@xmailserver.org wrote:
For threadlets, it might be. Now think about a task wanting to dispatch N
parallel AIO requests as N independent syslets.
Think about this task having USEDFPU set, so the FPU context is dirty.
When it returns from async_exec, with one of
On 2/28/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
130 lines skipped...
Yeah, I edited it down a lot before sending it. :-)
I have only one question - wasn't it too lazy to write all that? :)
I'm pretty lazy all right. But occasionally an interesting problem
(and revamping AIO is
On 2/28/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
130 lines skipped...
Yeah, I edited it down a lot before sending it. :-)
I have only one question - wasn't it too lazy to write all that? :)
I'm pretty lazy all right. But occasionally an interesting problem
(and revamping AIO is very
On 2/27/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
I think what you are not hearing, and what everyone else is saying
(INCLUDING Linus), is that for most programmers, state machines are
much, much harder to program, understand, and debug compared to
multi-threaded code. You may disagree (were
On 2/27/07, Theodore Tso [EMAIL PROTECTED] wrote:
I think what you are not hearing, and what everyone else is saying
(INCLUDING Linus), is that for most programmers, state machines are
much, much harder to program, understand, and debug compared to
multi-threaded code. You may disagree (were
On 2/25/07, Trent Waddington <[EMAIL PROTECTED]> wrote:
On 2/26/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> I know it's fun to blame everything on Redmond, but how about a
> simpler explanation?
Says the master of conspiracy.
Yes, I rather chuckled at the irony a
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote:
> Busy-wait loops were a rhetorical flourish, I grant you.
Thats a complicated fancy way of saying you were talking rubbish ?
No, it's a way of saying "yes, there are deliberate performance limits
in the driver code, but they're harder to explain
On 2/25/07, Alan [EMAIL PROTECTED] wrote:
Busy-wait loops were a rhetorical flourish, I grant you.
Thats a complicated fancy way of saying you were talking rubbish ?
No, it's a way of saying yes, there are deliberate performance limits
in the driver code, but they're harder to explain than
On 2/25/07, Trent Waddington [EMAIL PROTECTED] wrote:
On 2/26/07, Michael K. Edwards [EMAIL PROTECTED] wrote:
I know it's fun to blame everything on Redmond, but how about a
simpler explanation?
Says the master of conspiracy.
Yes, I rather chuckled at the irony as I wrote that one
On 2/25/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
Fundamentally a kernel thread is just its
EIP/ESP [on x86, similar on other architectures] - which can be
saved/restored in near zero time.
That's because the kernel address space is identical in every
process's MMU context, so the MMU doesn't
On 2/25/07, Alan <[EMAIL PROTECTED]> wrote:
> of other places too. Especially when the graphics chip maker explains
> that keeping their driver source code closed isn't really an attempt
> to hide their knowledge under a bushel basket. It's a defensive
> measure against having their retail
On 2/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Ok, but this is not realistic. I agree that if Evil Linker only adds
two hooks "void pop_server_starting(), void pop_server_stopping()", he
can get away with that.
But... how does situation change when Evil Linker does #include
from his
On 2/25/07, Pavel Machek [EMAIL PROTECTED] wrote:
Ok, but this is not realistic. I agree that if Evil Linker only adds
two hooks void pop_server_starting(), void pop_server_stopping(), he
can get away with that.
But... how does situation change when Evil Linker does #include
On 2/25/07, Alan [EMAIL PROTECTED] wrote:
of other places too. Especially when the graphics chip maker explains
that keeping their driver source code closed isn't really an attempt
to hide their knowledge under a bushel basket. It's a defensive
measure against having their retail margins
On 2/25/07, Ingo Molnar [EMAIL PROTECTED] wrote:
Fundamentally a kernel thread is just its
EIP/ESP [on x86, similar on other architectures] - which can be
saved/restored in near zero time.
That's because the kernel address space is identical in every
process's MMU context, so the MMU doesn't
On 2/24/07, Davide Libenzi wrote:
Ok, roger that. But why are you playing "Google & Preach" games to Ingo,
that ate bread and CPUs for the last 15 years?
Sure I used Google -- for clickable references so that lurkers can
tell I'm not making these things up as I go along. Ingo and Alan have
On 2/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> This is a fundamental misconception. [...]
> The scheduler, on the other hand, has to blow and reload all of the
> hidden state associated with force-loading the PC and wherever your
> architecture keeps its TLS (maybe not the whole TLB, but
On 2/23/07, Ingo Molnar [EMAIL PROTECTED] wrote:
This is a fundamental misconception. [...]
The scheduler, on the other hand, has to blow and reload all of the
hidden state associated with force-loading the PC and wherever your
architecture keeps its TLS (maybe not the whole TLB, but not
On 2/24/07, Davide Libenzi davidel@xmailserver.org wrote:
Ok, roger that. But why are you playing Google Preach games to Ingo,
that ate bread and CPUs for the last 15 years?
Sure I used Google -- for clickable references so that lurkers can
tell I'm not making these things up as I go along.
On 2/23/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
which costs you a D-cache stall.) Now put an sprintf with a %d in it
between a couple of the syscalls, and _your_ arch is hurting. ...
er, that would be a %f. :-)
Cheers,
- Michael
-
To unsubscribe from this list: send th
Russell, thanks again for offering to look at this; the more oopses
and soft lockups I see on this board, the more I think you're right
and we have an IRQ handling race.
Here's the struct irqchip setup:
/* mask irq, refer ssection 2.6 under chip 8618 document */
static void
I wrote:
(On a pre-EABI ARM, there is even a substantial
cache-related penalty for encoding the syscall number in the syscall
opcode, because you have to peek back at the text segment to see it,
which costs you a D-cache stall.)
Before you say it, I'm aware that this is not directly relevant
On 2/23/07, Zach Brown <[EMAIL PROTECTED]> wrote:
I'd love to see a generic implementation of RCU hashing that
subsystems can then take advantage of. It's long been on the fun
side of my todo list. The side I never get to :/.
There's an active thread on netdev about implementing an RCU hash.
Thanks for taking me at least minimally seriously, Alan. Pretty
generous of you, all things considered.
On 2/23/07, Alan <[EMAIL PROTECTED]> wrote:
That example touches back into user space, but doesnt involve MMU changes
or cache flushes, or tlb flushes, or floating point.
True -- on an
On 2/23/07, Alan <[EMAIL PROTECTED]> wrote:
> Do you not understand that real user code touches FPU state at
> unpredictable (to the kernel) junctures? Maybe not in a database or a
We don't care. We don't have to care. The kernel threadlets don't execute
in user space and don't do FP.
OK, having skimmed through Ingo's code once now, I can already see I
have some crow to eat. But I still have some marginally less stupid
questions.
Cachemiss threads are created with CLONE_VM | CLONE_FS | CLONE_FILES |
CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM. Does that mean they
share
OK, having skimmed through Ingo's code once now, I can already see I
have some crow to eat. But I still have some marginally less stupid
questions.
Cachemiss threads are created with CLONE_VM | CLONE_FS | CLONE_FILES |
CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM. Does that mean they
share
1 - 100 of 234 matches
Mail list logo
