Ingo Molnar wrote:
well, this is a performance problem if you are using threads. For normal
processes there is no need for a SMP cross-call, there TLB flushes are
local only.
But that would be ugly as hell:
so apache 2.0 would become slower with MSG_NOCOPY, whereas samba 2.2
Mike Harrold wrote:
Be careful. *4 is not a simple 2 substitution (by the compiler) if
the variable is signed. *4 translates to 3 instructions (on x86) if
it's an int.
I think you mean /4 is not the same as 2 if the variable is signed.
In general, non-widening multiplies give the same result
Daniel Phillips wrote:
DN_OPEN A file in the directory was opened
You open the top level directory and register for events. When somebody
opens a subdirectory of the top level directory, you receive
notification and register for events on the subdirectory, and so on,
down to
Alan Cox wrote:
I think its significant that two reports I have are FIC PA-2013 but not all.
What combination of chips is on the 2013 ?
Reading through my mail logs, I know a board, either FIC PA-2011 or FIC
PA-2007 (I seem to have changed my mind somewhere in history) with a
6.4G Quantum
Robert J. Bell wrote:
I have a Fujufilm FX-1400 digital camera that uses the USB Mass Storage
driver. I know it works because I had it working in 2.4.0-test12, and in
2.4.0 however I had a major system failure and lost my new kernel.
Fwiw, I have a Fujifilm FinePix 2400Zoom and it appears
ntry as me (Wales vs. France), but I
visit it every few months so there is some chance of me testing it on
that timescale. AFAIK there are no computer experts in the area to
enable remote access ;-)
It should be able to do UDMA33.
It does not look hopeful. Let us look at an old email:
From: Ja
Ralf Baechle wrote:
mremap. Linux specific but pretty much the same as mmap, but easier.
We just enforce that the virtual address of the source of mremap,
and the destination of mremap match on VIRT_INDEX_BITS.
Correct and as mremap doesn't take any address argument we won't break
any
Felix von Leitner wrote:
I cheated. I was only talking about open().
close() is of course more expensive then.
Other than that: where does the requirement come from?
Can't we just use a free list where we prepend closed fds and always use
the first one on open()? That would even increase
Ingo Molnar wrote:
struct native_file {
unsigned long master_fingerprint[8];
unsigned long file_fingerprint[8];
struct file file;
};
'fingerprints' are 256 bit, true random numbers. master_fingerprint is
global to the kernel and is
Ingo Molnar wrote:
this is what TUX uses. When a eg. static HTTP request arrives it sends
reply headers shortly after having checked file permissions and stuff (but
the file is not yet sent), with MSG_MORE set. Then it sends the file, and
sendfile() keeps MSG_MORE set right until the end of
Mikael Pettersson wrote:
There's a known bug in dd where it incorrectly attempts to truncate
the output file even though it's a block device.
dd also attempts to truncate a character device, therefore fails in the
same way.
The kernel should probably return EINVAL for this rather than EPERM.
Leslie Donaldson wrote:
I need a block of memory that can notify me or even a flag set when
it has been written to. I was thinking of letting the user code generate
some sort of page fault... Any random thoughts would be greatly
appreciated.
Look for the Boehm garbage collector. It has code
Mark Hahn wrote:
#ifdef SLOW_IO_BY_JUMPING
#define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
#else
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#define __SLOW_DOWN_IO "\noutb %%al,$0x19"
this is nutty: why can't udelay be used here? empirical measurements
in the thread show the
Richard B. Johnson wrote:
Slowing down I/O is absolutely necessary any time you set an index
register or a page register. For instance, to access the CMOS chip,
you write an index value out port 0x70, then you read or write from
port 0x71. Modern CPUs can execute instructions MUCH faster than
David S. Miller wrote:
Does ECN provide perceived benefits to the node using it?
Yes, endpoints and intermediate routers can tell the TCP sender about
congestion instead of TCP having to guess about it based upon observed
packet drop.
It is a major enhancement to performance over any
Dominik Kubla wrote:
On Fri, Jan 26, 2001 at 04:03:42PM +0100, Jamie Lokier wrote:
...
Applications tend not to. Do we care about those that do?
Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...
Yeah, Apache and Samba establish _outgoing_ connections with fixed
David S. Miller wrote:
People must fix their firewalls, there is no other way to
fix the problem and get ECN properly deployed. I'm ceasing
conversation on this thread from this point forward.
I suggest the ISPs fix their firewalls to strip ECN coming from their
Linux clients, providing a
David S. Miller wrote:
The connection failed, RST means connection reset. RST means all
state is corrupt and this connection must die. It cannot be
interpreted in any other way.
Therefore build a new connection, using a new source port if necessary.
-- Jamie
-
To unsubscribe from this
David S. Miller wrote:
Every single connection to ECN-broken sites would work as normal - it
would just take an extra few seconds. Instead of "Hotmail doesn't
work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
use Yahoo". A few million of those, and suddenly
James Sutherland wrote:
I was not suggesting ignoring these. OTOH, there is no reason to treat an
RST packet as "go away and never ever send traffic to this host again" -
i.e. trying another TCP connection, this time with ECN disabled, would be
acceptable.
Using a different source port
Lars Marowsky-Bree wrote:
First, you are ignoring a TCP_RST, which means "stop trying".
That's why we stop when we receive the second TCP RST.
It's just like dropping due to congestion, which is of course perfectly
safe in moderation.
You would have to retry a connection with a new source
Lars Marowsky-Bree wrote:
If connect() suddenly did two connection attempts instead of one, just how
many timeouts might that break?
Timeouts are already broken by applications that repeatedly call
connect(). You'd get better timeout behaviour by letting the kernel
enforce backoff.
Why?
Gregory Maxwell wrote:
Why? Why not just zero them, and get both security and compatibility...
Eeek! NO NO NO NO NO NO NO NO!
For ECN that would have worked, but that doesn't mean that something
couldn't have been implimented there that wouldn't have worked that way..
I think that
Dax Kelson wrote:
Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
Does ECN provide perceived benefits to the node using it?
Why are you even making suggestions when you haven't even read the RFC?
It seems that knowing what ECN is would be prerequisite to engaging in
discussion
H. Peter Anvin wrote:
It is; you'd have to specify "eax" as a clobber value, and that is
undesirable.
For outb_p, EAX is used, usually for the last time, in the preceding
"out" instruction so clobbering it is not a big deal.
For inb_p, you first have to copy EAX to another register before
Stefani Seibold wrote:
The inline function is the best choice, because it it full compatible to old
old printk. No side effects are expeted.
What is the difference?
I can't think of any difference between:
#define printk(format, args...) ((int) 0)
and:
static inline int printk_inline
Gregory Maxwell wrote:
There is nothing silly with the decision, davem is simply a modern day
internet hero.
No. If it were something essential, perhaps, but it's just a minor
performance tweak to cut packet loss over congested links. It's not
IPv6. It's not PMTU. It's not even
Andi Kleen wrote:
I get the same IP about 2/3 of the time, so it is pretty important
to avoid killing connections until after the new IP is known.
I prefer it when the IP is killed as soon as possible so that I can see
when the connection is lost (ssh sessions get killed etc.)
I like it
Eric S. Raymond wrote:
Tom Rini [EMAIL PROTECTED]:
Only sort-of. There are some cases where you can get away with that.
Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC,
always (right?)
Yes. So the right answer there isn't to use a derivation but to say:
Richard Henderson wrote:
No, the problem is not with which section, but what flags that
section should have. If you put only const data in a section,
then the section should have SHF_WRITE clear. Conversely, if
you put writable data in a section then SHF_WRITE should be set.
Now, one
James Sutherland wrote:
Note the derived work; there is no way on this earth (or any other) that
you could regard the device's firmware as being a derived work of the
driver!
The same is true if you add another completely new and separately
written .c source file: the new file is not a
Kurt Roeckx wrote:
You should never return from userspace to kernelspace. The
only way to go from user space to kernel space should be by using
a system call.
That does actually happen on x86. The kernel puts a small code fragment
called the trampoline on the user mode stack, which is run
Chris Wedgwood wrote:
By the way, the context stored on the stack is entirely a user
space context, however it does include some information from the
kernel that may be useful to user space, such as a page fault
address.
I actually (ab)used this for userspace paging with
[EMAIL PROTECTED] wrote:
Of course, not looking at the sets upon a zero return is a fairly obvious
optimization as there is little point in doing so.
No; a fairly obvious optimisation is to avoid calling FD_ZERO if you
can clear the bits individually when you test them.
When you examine the
Alexander Viro wrote:
Erm... "Limit reached" != "crash a machine"... Root has some reserve.
Then things have improved. I've crashed machines before this way...
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
dean gaudet wrote:
an example of brokenness in the traditional fd API is close-on-exec --
there's a race between open()/socket()/pipe() and fcntl(FD_CLOEXEC) during
which if another thread does a fork() it's possible the child will inherit
an fd it shouldn't... working around it is painful.
Andi Kleen wrote:
On Sun, Sep 03, 2000 at 05:22:44AM +0200, Jamie Lokier wrote:
I just thought I'd mention that you can do zero copy TCP in and out
*without* any page marking schemes. All you need is a network card with
quite a lot of RAM and some intelligence. An Alteon could do
Linus Torvalds wrote:
Proof: the data to be sent out is in RAM. In fact, often it is cached
in the CPU these days. In order to start sending out the packet, the
smart card has to move all of the data from RAM/cache over the bus to
the card. It can only start actually sending after
Alan Cox wrote:
It's not faster than card-card DMA, which falls out naturally from my
zero-copy proposal :-)
We already support card-card DMA for routing with fastrouting
..but not for user space proxies which was the above's context.
Still, the fastrouting proves card-card DMA actually
Alan Cox wrote:
read/recv block while the NIC DMAs into user space main memory.
Thats actually not always a win either. A DMA to user space flushes
those pages out of cache which isnt so ideal if the CPU wants
them. Some of the results are suprisingly counter-intuitive like this
Does it
Alexander Viro wrote:
*((unsigned long *)(x)) = NULL;
free_page(foo()) and we've got problems...
Alan really meant
*((unsigned long *)(x)) = NULL;
and screw you if it's not an lvalue.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Alan Cox wrote:
struct page of course). Note that it doesn't matter if another thread,
and this includes truncate/write in another thread, clobbers the page
data. That's just the normal effect of two concurrent writers to the
same memory.
Oh it does matter. You might send out a page
Linus Torvalds wrote:
(The "invalidate on write" is the sane way of doing SMP cache coherency,
which is probably why. Trying to have shared dirty cache-lines is just
not a viable option in the end).
With DMA from a device -- "snoop and update" still results in only one
owner of the dirty
Alan Cox wrote:
Alan, can you send me again the list of CPUs you think
is worth using 486 string routines.
Sorry, i lost your previous mail.
I suspect it is
486
K5
IDT Winchip
Rise
NexGen
Take a look at
http://now.cs.berkeley.edu/Td/bcopy.html
Ricky Beam wrote:
Tell me, would you like this done to you? You may assume typical
corporate enhancements: no PGP, filter runs on Windows 2000, any
unknown headers get stripped out, etc.
... message size restrictions, attachment mangling, false virus detection...
... restricted From:
Timur Tabi wrote:
Well, if it really is just his hobby, then he shouldn't be chanting
the "World Domination" mantra.
Why not? World Domination is my hobby too :-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Well, now GCC does CSE across "asm" and will eliminate memory loads,
even though it may not move them! I suspect it always did CSE across
"asm" and we just never got hit by the bug.
dummy_lock trick is equivalent to "memory" clobber.
For GCC 2.7.2 yes. For
Russell King wrote:
*a silent hard disk hard disk is no longer feasible since kernel
2.2.11*.
Yes it is. I have one of my machines (which NFS serves a NFS root
client, both of which are on 24 hours a day) capable of spinning
down for up to 4 hours at a time, with no kernel modifications
Russell King wrote:
With laptops, people are willing
to assume the RAM is reliable -- accidentally pulling the plug out won't
lose the data.
But a buggy apm implementation and the battery running down can.
Well, perhaps the risk is worth it.
-- Jamie
-
To unsubscribe from this list:
Linus Torvalds wrote:
It's about the fact that when I chose the GPL, I did it because I wanted
the source-code to be free and unencumbered. Forever. Whether I maintained
that code or not. I didn't want my code to have any extra rules and
regulations - the GPLv2 is already quite complex
Albert D. Cahalan wrote:
You can say it louder but you can't say it clearer. I'd love to know that
my surname shows up correctly everywhere. asbestos BTW, mutt shows MIME
patches in plain text without any problems /
That would be the "H=F8jland" in your .sig, right?
No problem, '=' is
Michael Elizabeth Chastain wrote:
A source control system so that curious people could do the equivalent of
"cvs annotate" and figure out who wrote particular pieces?
Note convinced about "cvs annotate". Maybe annotation with version
numbers. But "cvs diff" and "cvs update" are very
Lars Marowsky-Bree wrote:
I still don't see how processor traces will tell me what ordering
guarantees I can rely on across the range of processors.
It will tell you when your assumptions were wrong.
Indeed. Like testing, but better.
-- Jamie
-
To unsubscribe from this list: send the
Jeff V. Merkey wrote:
This means it completely unnecessary to assert LOCK# for the unlock
case, since there are no ordering issues persay - the other processors
are spinning on the lock already and cannot get through.
Yes I know I left out the context. Doesn't change what I'm about to
say.
Larry McVoy wrote:
Development:
In addition, by maintaining the system in CVS we can offer much
faster and convenient source updates than are currently available
from other Linux-based systems currently available.
Err, "faster"? The following is the moral equiv
Rik van Riel wrote:
The main difference between Linux and Netware here is the
fact that Linux has a real userland, which can touch the
pages on its own without going through the kernel.
This causes "spontaneously" dirtied or accessed pages,
meaning that we really want to use the hardware
Larry McVoy wrote:
On the other hand, if you do a
find . -type f | xargs touch
time cvs update .
it will melt down your DSL line for what seems forever. I killed it after
20 minutes, I have better things to do with my bandwidth. It's pretty
clear that CVS is comparing
David A. Gatwood wrote:
I'm sorry, but I can't believe those numbers. It takes longer than 1.6
seconds to stat all the kernel directories unless the BK machine has a
huge disk cache. It sounds like the BK server was a much more powerful
machine.
Use treescan for fast stat preload :-)
Larry McVoy wrote:
That's a benefit [for BK] of having changesets, I only need to compare
the ChangeSet file to know that 4 files were updated 2 were moved, and
5 were created, then I move those *portions* of those files across the
wire.
What happens when I lose the ChangeSet file, or
Larry McVoy wrote:
We have a hack in BK for this, at least I think we do, where we can look at
the time stamps to notice that you haven't modified the files. We don't
use it because of NFS screwing up timestamps. I suppose we could enable
it on a per repository basis so that if you knew
David A. Gatwood wrote:
I'd love to see a filesystem feature where I could efficiently identify
"changed files", where "changed" is defined by last time this application
checked or something similar.
An in-filesystem revision number would do the trick. Could be REALLY
efficient. All
Jes Sorensen wrote:
It took me a little while in the beginning to convince Alteon to open
up and provide docs, but since they saw the light they have been
extremely helpful and went much further in their openness than I had
ever expected or dared to hope for.
And now it's really showing in
Todd wrote:
While I agree with what's going on right now, the recent purchase of
Alteon by Nortel (primarily for their switch line, not for the
NICs) leaves quite a bit of doubt in my mind about the future of the card
and the openness of the firmware in particular.
Why not raise your
Dave Zarzycki wrote:
Personally speaking, I always thought it would be nice if the kernel
flushed dirty buffers right before a disk spins down. It seems silly to me
that a disk can spin down with writes pending.
Absolutely. That allows more time spun down too.
-- Jamie
-
To unsubscribe from
Jes Sorensen wrote:
So? I have one of those letters in my name as well, doesn't mean I put
it in the From line or in the code that I write. Or do you want us all
to start using a compiler and editors that will understand full UTF8
so everybody who use non roman character sets have their names
Theodore Y. Ts'o wrote:
I've told Linus several times about this problems but he puts out one
test release after the other without this fixed.
This is kinda important, I run DNS tools which are threaded amongst
numerous other threaded programs a lot. What needs to be done to
Andrea Arcangeli wrote:
Andrea - latency is time measured and perceived. Doing it time based
seems to make reasonable sense. I grant you might want to play with
the weighting per [device]
Right. Perception.
When you have a device that writes a request every two seconds you still
want it
Ralf Baechle wrote:
From some random Linux source tree's .hdepend:
/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
/usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
/usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
@touch
Jamie Lokier wrote:
@touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h
[...]
.cvsignore
Oops, ignore me 'cos I obviously didn't read what I replied to.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Felix von Leitner wrote:
The kernel interface seems to be:
* supply an O_DIRECTORY flag to open()
O_DIRECTORY means "refuse to open if not a directory".
Old kernels ignore the flag.
So Glibc then calls fstat() to check it's really a directory.
(opendir() is required to fail on
[EMAIL PROTECTED] wrote:
Sure the global system is slower. But the "interactive feel" is faster.
Let's pop up little buttons to make it "feel" faster.
If little buttons pop up quickly when I click on them, then yes that's
better interactive feel. Sometimes the disk is involved in this.
Linus, please think this over before applying Andi's patch.
Andi Kleen wrote:
The problem is really that SI_SIGIO is negative, but it should be positive
to make SI_FROMUSER return false on it.
This is an old problem. There was a thread on this topic last March.
Look for "accept()
Julian Anastasov wrote:
I'm talking about test8. __SI_CODE is in 2.4, not in 2.2.
The handling is very different. We can't wait for si_code==SI_SIGIO
in 2.4 anymore. SI_SIGIO is used only in 2.2:fs/fcntl.c. 2.4 stores
POLL_xxx in si_code instead of SI_SIGIO.
Why does it do that?
Horst von Brand wrote:
I'd call emacs consistently not being able to start an ls on a 16Mb machine
much worse than a surprise...
Hint: Think about how emacs would go about doing that...
vfork ;-)
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Bernhard Rosenkraenzer wrote:
Which still makes it an broken, experimental, unreleased and unofficial
compiler, with all the consequences I said.
I agree about the "unreleased and unofficial" part, but it's not quite
that broken and experimental. Everything that is shipped with Red Hat
Bernhard Rosenkraenzer wrote:
Hah! Even the preprocessor is broken in 2.96. I have to use an older one.
Broken in what way? Testcase?
This is the worst:
#define half(x) ((x) / 2)
#define apply(...) apply2 (__VA_ARGS__)
#define apply2(f,x) f (x)
apply (half, X)
Expands
[EMAIL PROTECTED] wrote:
If we played some "zippy" music that would add to the "feel". Of
course, we could actually use benchmarks instead.
Benchmarks, famed for their universal appeal :-)
And, to me, if kernel compiles take longer, I don't care how fast it "feels".
A kernel compile _by
Ingo Molnar wrote:
They seem focused on keeping us in the dark ages. We need tools to make
it faster and easier for folks to perform kernel development and make
field support of Linux easier.
tools can sometimes bring the dark ages faster than anything else.
However, if Jeff would
Andrea Arcangeli wrote:
BTW Look also into asm-i386/bitops.h and dummy cast to some crap there.
Are you impressed? 8)
Yep 8). If we add "memory" such stuff could be removed I think. As far I
can see the object of such stuff is to cause gcc to say `I'm too lazy to
see exactly what memory
Andrea Arcangeli wrote:
int a = *p;
__asm__ __volatile__("" : :);
a = *p;
(to do two explicit reads)
Sorry, that does just one read, kgcc (old stable gcc) and also with
gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
I wrote the above not
Linus Torvalds wrote:
"volatile" should be equivalent to clobbering memory, although the gcc
manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
Linus Torvalds wrote:
Change it to something like
__asm__("":"=r" (x):"0" (x));
and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory references
Linus Torvalds wrote:
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That would be silly: an asm that just
wipes all memory would not be a very useful asm (or rather, it would have
just _one_ use: "execve()"). So "memory" really says
Andrea Arcangeli wrote:
Said that if your compiler puts the read before the spin_lock without the
memory clobber, it is allowed to do that, and in such case you would proof
it was a real world bug (not just a "documentation" one).
Yes, it does.
Or maybe your testcase was a bit different
Andrea Arcangeli wrote:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ gcc -v
Reading specs from
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
*p = 1;
in the assembler we'll then
David Woodhouse wrote:
But how much work would it require to do so? If your theoretical vendor of
closed-source compiler backends were to believe that a shared lib of the
GCC frontend would be legal, surely they'd just make it shared themselves,
then use it as such? It's hardly a effective
Andrea Arcangeli wrote:
int * p;
[...]
spin_lock(lock);
a = *p;
spin_unlock(lock);
spin_lock(lock);
b = *p;
spin_unlock(lock);
[With "memory" clobber"] the [second] reload of the address of `p'
isn't necessary and gcc is wrong in
Alan Cox wrote:
It isnt a sensible answer. Think about a threaded web server firing off
cgi scripts. You should probably kill those with the same mm. Especially if
you have an unclone(CLONE_MM) since you can then unshare the VM for a thread
and exec stuff off it
Think about a single
Martin Josefsson wrote:
I've been trying to get my machine to swap but that seems hard with this
new patch :) I have 0kB of swap used after 8h uptime, and I have been
compiling, moving files between partitions and running md5sum on files
(that was a big problem before, everything ended up on
[EMAIL PROTECTED] wrote:
walk = out;
while(nfds 0) {
poll_table *tmp = (poll_table *) __get_free_page(GFP_KERNEL);
if (!tmp) {
Shouldn't this be GFP_USER? (Which would also conveniently fix the
problem Victor's pointing out...)
-- Jamie
-
To
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
walk = out;
while(nfds 0) {
poll_table *tmp = (poll_table *) __get_free_page(GFP_KERNEL);
if (!tmp) {
Shouldn't this be GFP_USER? (Which would also conveniently fix the
problem
Philip J. Mucci wrote:
Basically, reading the counters is a 2 step process: read the mmapped
virtual counters and add that to the contents of rdpmc(). This means
that (at least for the x86 series) the kernel interface only needs to
'guard' access to the MSR to make sure the user doesn't set
Alexander Viro wrote:
ITYM "cute". As in "cute dancing paperclip". As colourized ls.
Hey, colour ls is _useful_!
Or --ignore-fail-on-non-empty as rmdir option. Or "let's replace config
files with directories full of one-liners since packagers can't be arsed
to learn sed(1)" religion.
David S. Miller wrote:
These items are specifically placed into the data section, not the
BSS, because these alignment games are not possible in the BSS.
That would mean the BSS needs support alignment games.
The problem is it doesn't work, please go try it.
So until it does
Keith Owens wrote:
Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
and it should do what you want.
Heck, section ".bss" might give you the alignment without the allocation
but I'm not as confident about that.
Call me mad but you could actually try this instead of
Henning P. Schmiedehausen wrote:
Hey, colour ls is _useful_!
Use white background Xterm. Come again?
Ugh!
One of the biggest mistakes RH ever did was happily jumping off _that_
cliff to follow SuSE.
Colour ls predates both Red Hat and SuSE.
-- Jamie
-
To unsubscribe from this list: send
[EMAIL PROTECTED] wrote:
Looking at the [network] code, I don't see any places where "current"
is not valid.
Got some examples?
Damn I'm being dense tonight. No, that bug was due to calling "current"
from the wrong process context, not from an invalid context.
(Self-flagellate,
Kurt Garloff wrote:
I could not agree more. Normally, you'd better kill a foreground task
(running nice 0) than selecting one of those background jobs for some
reasons:
* The foreground job can be restarted by the interactive user
(Most likely, it will be only netscape anyway)
* The
Linus Torvalds wrote:
You can also still do the stack pointer plaything by just using
indirection: and when you context switch you switch the pointer around at
the base of the per-cpu interrupt stack.
Indirection, à la "current = *(stack ~8191)" might not be a bad idea
in general. As Ralf
1 - 100 of 580 matches
Mail list logo
