On 8/9/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > You keep claiming that hrtimers are so incredibly expensive; but for
> > msleep()... which is mostly called during driver init ... I really don't
> &g
On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> You keep claiming that hrtimers are so incredibly expensive; but for
> msleep()... which is mostly called during driver init ... I really don't
> buy that it's really expensive. We're not doing this a gazilion times
> per second obviously...
On 8/8/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
You keep claiming that hrtimers are so incredibly expensive; but for
msleep()... which is mostly called during driver init ... I really don't
buy that it's really expensive. We're not doing this a gazilion times
per second obviously...
Yes.
On 8/9/07, Denis Vlasenko [EMAIL PROTECTED] wrote:
On 8/8/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
You keep claiming that hrtimers are so incredibly expensive; but for
msleep()... which is mostly called during driver init ... I really don't
buy that it's really expensive. We're
On 8/2/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> > > Please, copy strtonum() from BSD instead. Nobody needs another
> > > home-grown converter.
> >
> > BSD's strtonum(3) is a detestful, horrible shame.
> >
> > The strtol_check_range() I implemented here does _all_ that strtonum()
> > does,
On 8/2/07, Alexey Dobriyan [EMAIL PROTECTED] wrote:
Please, copy strtonum() from BSD instead. Nobody needs another
home-grown converter.
BSD's strtonum(3) is a detestful, horrible shame.
The strtol_check_range() I implemented here does _all_ that strtonum()
does, plus is generic
Hi,
Attached patch deinlines and moves big functions from .h to .c files
in drivers/scsi/aic7xxx/*. I also had to add prototypes for ahc_lookup_scb
and ahd_lookup_scb to .h files.
No other code changes made.
Compile-tested on i386 and x86-64.
Total .text size reduction: ~60k in 64 bits, ~90k in
Hi,
Attached patch deinlines and moves big functions from .h to .c files
in drivers/scsi/aic7xxx/*. I also had to add prototypes for ahc_lookup_scb
and ahd_lookup_scb to .h files.
No other code changes made.
Compile-tested on i386 and x86-64.
Total .text size reduction: ~60k in 64 bits, ~90k in
On Wednesday 18 July 2007 22:04, Andi Kleen wrote:
> Better just write less bloated code. Perhaps mandatory bloatometer
> runs during -rc*s for kernels with minimal config with public code pig shame
> lists
> similar to the regression lists are useful. Anyone volunteering?
>
> I suspect there is
Hi Satyam,
On Monday 23 July 2007 17:05, Satyam Sharma wrote:
> There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
> that was unnecessary and not required for the correctness of those APIs.
> All that superfluous stuff was also unnecessarily disallowing compiler
>
Hi Satyam,
On Monday 23 July 2007 17:05, Satyam Sharma wrote:
There was a lot of bogus stuff that include/asm-i386/bitops.h was doing,
that was unnecessary and not required for the correctness of those APIs.
All that superfluous stuff was also unnecessarily disallowing compiler
optimization
On Wednesday 18 July 2007 22:04, Andi Kleen wrote:
Better just write less bloated code. Perhaps mandatory bloatometer
runs during -rc*s for kernels with minimal config with public code pig shame
lists
similar to the regression lists are useful. Anyone volunteering?
I suspect there is also
On Thursday 21 June 2007 21:32, Mathieu Desnoyers wrote:
> Let's take arch/i386/boot/video.h as an example:
>
> it defines
>
> struct card_info {
> const char *card_name;
> int (*set_mode)(struct mode_info *mode);
> int (*probe)(void);
> struct mode_info *modes;
On Thursday 21 June 2007 21:32, Mathieu Desnoyers wrote:
Let's take arch/i386/boot/video.h as an example:
it defines
struct card_info {
const char *card_name;
int (*set_mode)(struct mode_info *mode);
int (*probe)(void);
struct mode_info *modes;
On Sunday 22 July 2007 00:16, Oleg Verych wrote:
> * From: Andi Kleen <[EMAIL PROTECTED]>
> * Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
> >
> > Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
> > it should generate better code than the old macro. Let's try it.
>
>
On Sunday 22 July 2007 00:16, Oleg Verych wrote:
* From: Andi Kleen [EMAIL PROTECTED]
* Date: Thu, 19 Jul 2007 11:54:53 +0200 (CEST)
Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
it should generate better code than the old macro. Let's try it.
Unfortunately such
On Tuesday 17 July 2007 00:42, Bodo Eggert wrote:
> > Please note that I was not trying to remove the 8K stack option right
> > now - heck, I didn't even add anything to feature-removal-schedule.txt
> > - all I wanted to accomplish with the patch that started this threas
> > was; a) indicate that
On Tuesday 17 July 2007 00:42, Bodo Eggert wrote:
Please note that I was not trying to remove the 8K stack option right
now - heck, I didn't even add anything to feature-removal-schedule.txt
- all I wanted to accomplish with the patch that started this threas
was; a) indicate that the 4K
On Thursday 05 July 2007 21:34, Andrew Morton wrote:
> On Thu, 5 Jul 2007 12:51:52 +0200
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
>
> > Using code from
> >
> > http://www.cs.uiowa.edu/~jones/bcd/decimal.html
> > (with permission from the author, Douglas
On Thursday 05 July 2007 21:34, Andrew Morton wrote:
On Thu, 5 Jul 2007 12:51:52 +0200
Denis Vlasenko [EMAIL PROTECTED] wrote:
Using code from
http://www.cs.uiowa.edu/~jones/bcd/decimal.html
(with permission from the author, Douglas W. Jones)
Neither of your patches had signed-off
On Friday 06 July 2007 08:35, Jesper Juhl wrote:
> On 06/07/07, Kaleem Khan <[EMAIL PROTECTED]> wrote:
> > Hello Kernel experts,
> >
> > I'd like to know whether there's a way to take some action (say
> > calling a routine) in
> > response to 'kill -9' before the process is terminated. I tend to
>
On Friday 06 July 2007 08:35, Jesper Juhl wrote:
On 06/07/07, Kaleem Khan [EMAIL PROTECTED] wrote:
Hello Kernel experts,
I'd like to know whether there's a way to take some action (say
calling a routine) in
response to 'kill -9' before the process is terminated. I tend to
think it's
On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > Removes conditional branch from schedule(). Code savings on my
> >usual config:
> >
> >textdata bss dec hex filename
> > 2921871 179895 180224 3281990 321446 vmlinux before
> > 2920141
On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
Removes conditional branch from schedule(). Code savings on my
usual config:
textdata bss dec hex filename
2921871 179895 180224 3281990 321446 vmlinux before
2920141 179847
On Monday 11 June 2007 02:56, Paul Mundt wrote:
> On Mon, Jun 11, 2007 at 01:59:00AM +0200, Denis Vlasenko wrote:
> > On Sunday 10 June 2007 20:58, Rene Herman wrote:
> > > All that stuff only serves to multiply the speed at which a fixed
> > > percentage of content
On Monday 11 June 2007 02:56, Paul Mundt wrote:
On Mon, Jun 11, 2007 at 01:59:00AM +0200, Denis Vlasenko wrote:
On Sunday 10 June 2007 20:58, Rene Herman wrote:
All that stuff only serves to multiply the speed at which a fixed
percentage of content obsoletes itself. When it's still new
On Sunday 10 June 2007 20:58, Rene Herman wrote:
> All that stuff only serves to multiply the speed at which a fixed percentage
> of content obsoletes itself. When it's still new and shiny, sure, stuff will
> get translated but in no time at all it'll become a fragmented mess which
> nobody
On Sunday 10 June 2007 20:58, Rene Herman wrote:
All that stuff only serves to multiply the speed at which a fixed percentage
of content obsoletes itself. When it's still new and shiny, sure, stuff will
get translated but in no time at all it'll become a fragmented mess which
nobody ever
On Thursday 24 May 2007 21:56, Uwe Bugla wrote:
> Please note:
>
> 1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
>
> Questions:
>
> 1. What is the technical need / progress of module ssb please?
>
> 2. If Andrew Morton's guidelines clearly say: "Do test your
On Thursday 24 May 2007 21:56, Uwe Bugla wrote:
Please note:
1. IRQ 255 looks very idiotic, doesn't it? It does not exist at all, does it?
Questions:
1. What is the technical need / progress of module ssb please?
2. If Andrew Morton's guidelines clearly say: Do test your patches on
Theodore Tso wrote:
>
> One of the big problems of using a filesystem as a DB is the system
> call overheads. If you use huge numbers of tiny files, then each
> attempt read an atom of information from the DB takes three system
> calls --- an open(), read(), and close(), with all of the
Theodore Tso wrote:
One of the big problems of using a filesystem as a DB is the system
call overheads. If you use huge numbers of tiny files, then each
attempt read an atom of information from the DB takes three system
calls --- an open(), read(), and close(), with all of the overheads in
Hi Tom.
On Thursday 19 April 2007 21:00, Tom Strader wrote:
> This is the final output from my kernel as I try to launch busybox
> (/sbin/init is linked to /bin/busybox)
> As it launches the kernel looks for libraries which do not exist (not
> sure why), but it appears to find /lib/libcrypt.so.1
On Saturday 21 April 2007 18:00, Ingo Molnar wrote:
> correct. Note that Willy reniced X back to 0 so it had no relevance on
> his test. Also note that i pointed this change out in the -v4 CFS
> announcement:
>
> || Changes since -v3:
> ||
> || - usability fix: automatic renicing of kernel
On Saturday 21 April 2007 18:00, Ingo Molnar wrote:
correct. Note that Willy reniced X back to 0 so it had no relevance on
his test. Also note that i pointed this change out in the -v4 CFS
announcement:
|| Changes since -v3:
||
|| - usability fix: automatic renicing of kernel threads
Hi Tom.
On Thursday 19 April 2007 21:00, Tom Strader wrote:
This is the final output from my kernel as I try to launch busybox
(/sbin/init is linked to /bin/busybox)
As it launches the kernel looks for libraries which do not exist (not
sure why), but it appears to find /lib/libcrypt.so.1 and
Hi kernel people,
Just upgraded by home box to 2.6.20.7. Wow.
* Reiser3 mount times are drastically reduced,
even when journal replay is needed
(I have few 100Gb+ reiser3 partitions mounted at boot)
* sit pseudo-interface is gone. In previous kernel, I tried
to disable it in kernel config
Hi kernel people,
Just upgraded by home box to 2.6.20.7. Wow.
* Reiser3 mount times are drastically reduced,
even when journal replay is needed
(I have few 100Gb+ reiser3 partitions mounted at boot)
* sit pseudo-interface is gone. In previous kernel, I tried
to disable it in kernel config
On Thursday 08 March 2007 18:28, Linus Torvalds wrote:
> The sad part is that there really is no reason why the BSD crowd couldn't
> have done recvmsg() as an "extended read with per-system call flags",
> which would have made things like O_NONBLOCK etc unnecessary, because you
> could do it
On Thursday 08 March 2007 18:28, Linus Torvalds wrote:
The sad part is that there really is no reason why the BSD crowd couldn't
have done recvmsg() as an extended read with per-system call flags,
which would have made things like O_NONBLOCK etc unnecessary, because you
could do it just
Hi,
On Sunday 18 March 2007 22:06, Robert P. J. Day wrote:
> p.s. just FYI, i ran my "find dead CONFIG variables" script on the
> entire tree and, as we speak, there are 316 preprocessor tests that
> are testing variables of the form "CONFIG_whatever" for which that
> option is not set anywhere
Hi,
On Sunday 18 March 2007 22:06, Robert P. J. Day wrote:
p.s. just FYI, i ran my find dead CONFIG variables script on the
entire tree and, as we speak, there are 316 preprocessor tests that
are testing variables of the form CONFIG_whatever for which that
option is not set anywhere in the
On Saturday 10 March 2007 13:16, Mockern wrote:
> I have a problem with cat < /dev/my_ttyS0 (see strace output below).
> cat function is not blocked. I don't understand why it is not stopped
> at read(0, __ and terminated?
> Thank you
Because /dev/my_ttyS0 is probaly a null file.
Please show
On Saturday 10 March 2007 13:16, Mockern wrote:
I have a problem with cat /dev/my_ttyS0 (see strace output below).
cat function is not blocked. I don't understand why it is not stopped
at read(0, __ and terminated?
Thank you
Because /dev/my_ttyS0 is probaly a null file.
Please show
On Sunday 04 February 2007 01:55, David Schwartz wrote:
>
> > That's a bug, right? I couldn't find anything to that effect in IEEE
> > Std. 1003.1, 2004 Edition...
> >
> > Ciao,
> > Roland
>
> It's not a bug, there's no rational alternative. What would two indepedent
> file
On Sunday 04 February 2007 01:55, David Schwartz wrote:
That's a bug, right? I couldn't find anything to that effect in IEEE
Std. 1003.1, 2004 Edition...
Ciao,
Roland
It's not a bug, there's no rational alternative. What would two indepedent
file descriptors
On Tuesday 30 January 2007 04:40, Philippe Troin wrote:
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
> > return 0;
> > }
> >
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) & ~O_NONBLOCK);
> > return 0;
> > }
> >
> > If I
On Tuesday 30 January 2007 04:40, Philippe Troin wrote:
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) ~O_NONBLOCK);
return 0;
}
If I run nonblock in
On Monday 29 January 2007 18:00, Andrea Arcangeli wrote:
> On Sun, Jan 28, 2007 at 06:03:08PM +0100, Denis Vlasenko wrote:
> > I still don't see much difference between O_SYNC and O_DIRECT write
> > semantic.
>
> O_DIRECT is about avoiding the copy_user between cache and use
On Monday 29 January 2007 18:00, Andrea Arcangeli wrote:
On Sun, Jan 28, 2007 at 06:03:08PM +0100, Denis Vlasenko wrote:
I still don't see much difference between O_SYNC and O_DIRECT write
semantic.
O_DIRECT is about avoiding the copy_user between cache and userland,
when working
On Sunday 28 January 2007 16:30, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
> >> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> >>> On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >>&g
On Sunday 28 January 2007 16:18, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >> Denis Vlasenko wrote:
> >>> On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >>>> Phillip Susi wrot
On Sunday 28 January 2007 16:18, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
Phillip Susi wrote:
[...]
But even single-threaded I/O
On Sunday 28 January 2007 16:30, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
Denis Vlasenko [EMAIL PROTECTED] wrote:
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Thursday 25 January 2007 21:45
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include
#include
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
#include
On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
> Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> >> Denis Vlasenko wrote:
> >> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
>
On Saturday 27 January 2007 15:01, Bodo Eggert wrote:
Denis Vlasenko [EMAIL PROTECTED] wrote:
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
But even single-threaded I/O but in large quantities
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include unistd.h
#include fcntl.h
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> >> Phillip Susi wrote:
> >>> Denis Vlasenko wrote:
> >>>> You mean "You can use aio_write" ?
>
On Friday 26 January 2007 18:05, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > Which shouldn't be true. There is no fundamental reason why
> > ordinary writes should be slower than O_DIRECT.
>
> Again, there IS a reason: O_DIRECT eliminates the cpu overhead of the
>
On Friday 26 January 2007 18:05, Phillip Susi wrote:
Denis Vlasenko wrote:
Which shouldn't be true. There is no fundamental reason why
ordinary writes should be slower than O_DIRECT.
Again, there IS a reason: O_DIRECT eliminates the cpu overhead of the
kernel-user copy,
You assume
On Friday 26 January 2007 19:23, Bill Davidsen wrote:
Denis Vlasenko wrote:
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
Phillip Susi wrote:
Denis Vlasenko wrote:
You mean You can use aio_write ?
Exactly. You generally don't use O_DIRECT without aio. Combining the
two
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
> Phillip Susi wrote:
> > Denis Vlasenko wrote:
> >> You mean "You can use aio_write" ?
> >
> > Exactly. You generally don't use O_DIRECT without aio. Combining the
> > two is what g
On Thursday 25 January 2007 20:28, Phillip Susi wrote:
> > Ahhh shit, are you saying that fdatasync will wait until writes
> > *by all other processes* to thios file will hit the disk?
> > Is that thue?
>
> I think all processes yes, but certainly all writes to this file by this
> process. That
On Thursday 25 January 2007 16:44, Phillip Susi wrote:
> Denis Vlasenko wrote:
> > I will still disagree on this point (on point "use O_DIRECT, it's faster").
> > There is no reason why O_DIRECT should be faster than "normal" read/write
> > to lar
On Thursday 25 January 2007 16:44, Phillip Susi wrote:
Denis Vlasenko wrote:
I will still disagree on this point (on point use O_DIRECT, it's faster).
There is no reason why O_DIRECT should be faster than normal read/write
to large, aligned buffer. If O_DIRECT is faster on today's kernel
On Thursday 25 January 2007 20:28, Phillip Susi wrote:
Ahhh shit, are you saying that fdatasync will wait until writes
*by all other processes* to thios file will hit the disk?
Is that thue?
I think all processes yes, but certainly all writes to this file by this
process. That means
On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
Phillip Susi wrote:
Denis Vlasenko wrote:
You mean You can use aio_write ?
Exactly. You generally don't use O_DIRECT without aio. Combining the
two is what gives the big win.
Well, it's not only aio. Multithreaded I/O also
On Monday 22 January 2007 17:17, Phillip Susi wrote:
> > You do not need to know which read() exactly failed due to bad disk.
> > Filename and offset from the start is enough. Right?
> >
> > So, SIGIO/SIGBUS can provide that, and if your handler is of
> > void (*sa_sigaction)(int, siginfo_t
On Monday 22 January 2007 17:17, Phillip Susi wrote:
You do not need to know which read() exactly failed due to bad disk.
Filename and offset from the start is enough. Right?
So, SIGIO/SIGBUS can provide that, and if your handler is of
void (*sa_sigaction)(int, siginfo_t *, void *);
On Sunday 21 January 2007 13:09, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> >> Denis Vlasenko wrote:
> >>> On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >>>> example,
On Sunday 21 January 2007 13:09, Michael Tokarev wrote:
Denis Vlasenko wrote:
On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
Denis Vlasenko wrote:
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
example, which isn't quite possible now from userspace. But as long
On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
> Denis Vlasenko wrote:
> > On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> >> example, which isn't quite possible now from userspace. But as long as
> >> O_DIRECT actually writes data before
On Sunday 14 January 2007 10:11, Nate Diller wrote:
> On 1/12/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Most applications don't get the kind of performance analysis that
> Digeo was doing, and even then, it's rather lucky that we caught that.
> So I personally think it'd be best for libc or
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
> example, which isn't quite possible now from userspace. But as long as
> O_DIRECT actually writes data before returning from write() call (as it
> seems to be the case at least with a normal filesystem on a real block
> device - I don't
On Thursday 11 January 2007 16:50, Linus Torvalds wrote:
>
> On Thu, 11 Jan 2007, Nick Piggin wrote:
> >
> > Speaking of which, why did we obsolete raw devices? And/or why not just
> > go with a minimal O_DIRECT on block device support? Not a rhetorical
> > question -- I wasn't involved in the
On Thursday 11 January 2007 16:50, Linus Torvalds wrote:
On Thu, 11 Jan 2007, Nick Piggin wrote:
Speaking of which, why did we obsolete raw devices? And/or why not just
go with a minimal O_DIRECT on block device support? Not a rhetorical
question -- I wasn't involved in the discussions
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
example, which isn't quite possible now from userspace. But as long as
O_DIRECT actually writes data before returning from write() call (as it
seems to be the case at least with a normal filesystem on a real block
device - I don't
On Sunday 14 January 2007 10:11, Nate Diller wrote:
On 1/12/07, Andrew Morton [EMAIL PROTECTED] wrote:
Most applications don't get the kind of performance analysis that
Digeo was doing, and even then, it's rather lucky that we caught that.
So I personally think it'd be best for libc or
On Saturday 20 January 2007 21:55, Michael Tokarev wrote:
Denis Vlasenko wrote:
On Thursday 11 January 2007 18:13, Michael Tokarev wrote:
example, which isn't quite possible now from userspace. But as long as
O_DIRECT actually writes data before returning from write() call (as it
seems
On Wednesday 03 January 2007 21:26, Frank van Maarseveen wrote:
> On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
> > 64-bit inode numbers space is not yet implemented on Linux --- the problem
> > is that if you return ino >= 2^32, programs compiled without
> >
On Wednesday 03 January 2007 13:42, Pavel Machek wrote:
> I guess that is the way to go. samefile(path1, path2) is unfortunately
> inherently racy.
Not a problem in practice. You don't expect cp -a
to reliably copy a tree which something else is modifying
at the same time.
Thus we assume that
On Thursday 28 December 2006 10:06, Benny Halevy wrote:
> Mikulas Patocka wrote:
> >>> If user (or script) doesn't specify that flag, it doesn't help. I think
> >>> the best solution for these filesystems would be either to add new syscall
> >>> int is_hardlink(char *filename1, char *filename2)
On Thursday 11 January 2007 02:02, Neil Brown wrote:
> If regs->rax is unsigned long, then I would think the compiler would
> be allowed to convert
>
>switch (regs->rax) {
> case -514 : whatever;
>}
>
> to a no-op, as regs->rax will never have a negative value.
In C, you never
On Thursday 11 January 2007 02:02, Neil Brown wrote:
If regs-rax is unsigned long, then I would think the compiler would
be allowed to convert
switch (regs-rax) {
case -514 : whatever;
}
to a no-op, as regs-rax will never have a negative value.
In C, you never actually
On Thursday 28 December 2006 10:06, Benny Halevy wrote:
Mikulas Patocka wrote:
If user (or script) doesn't specify that flag, it doesn't help. I think
the best solution for these filesystems would be either to add new syscall
int is_hardlink(char *filename1, char *filename2)
(but I know
On Wednesday 03 January 2007 13:42, Pavel Machek wrote:
I guess that is the way to go. samefile(path1, path2) is unfortunately
inherently racy.
Not a problem in practice. You don't expect cp -a
to reliably copy a tree which something else is modifying
at the same time.
Thus we assume that the
On Wednesday 03 January 2007 21:26, Frank van Maarseveen wrote:
On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
64-bit inode numbers space is not yet implemented on Linux --- the problem
is that if you return ino = 2^32, programs compiled without
-D_FILE_OFFSET_BITS=64
On Thursday 04 January 2007 18:37, Linus Torvalds wrote:
> With 7+ million lines of C code and headers, I'm not interested in
> compilers that read the letter of the law. We don't want some really
> clever code generation that gets us .5% on some unrealistic load. We want
> good _solid_ code
On Thursday 04 January 2007 18:37, Linus Torvalds wrote:
With 7+ million lines of C code and headers, I'm not interested in
compilers that read the letter of the law. We don't want some really
clever code generation that gets us .5% on some unrealistic load. We want
good _solid_ code
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
> Denis Vlasenko wrote:
> > But O_DIRECT is _not_ about cache. At least I think it was not about
> > cache initially, it was more about DMAing data directly from/to
> > application address space to/from disks, savin
On Friday 05 January 2007 17:20, Bill Davidsen wrote:
Denis Vlasenko wrote:
But O_DIRECT is _not_ about cache. At least I think it was not about
cache initially, it was more about DMAing data directly from/to
application address space to/from disks, saving memcpy's and double
allocations
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
> Hugh Dickins wrote:
> In many cases the use of O_DIRECT is purely to avoid impact on cache
> used by other applications. An application which writes a large quantity
> of data will have less impact on other applications by using O_DIRECT,
On Thursday 04 January 2007 17:19, Bill Davidsen wrote:
Hugh Dickins wrote:
In many cases the use of O_DIRECT is purely to avoid impact on cache
used by other applications. An application which writes a large quantity
of data will have less impact on other applications by using O_DIRECT,
On Wednesday 03 January 2007 21:38, Linus Torvalds wrote:
> On Wed, 3 Jan 2007, Denis Vlasenko wrote:
> >
> > Why CPU people do not internally convert cmov into jmp,mov pair?
>
...
> It really all boils down to: there's simply no real reason to use cmov.
> It's not horr
On Wednesday 03 January 2007 17:03, Linus Torvalds wrote:
> On Wed, 3 Jan 2007, Grzegorz Kulewski wrote:
> > Could you explain why CMOV is pointless now? Are there any benchmarks
> > proving
> > that?
>
> CMOV (and, more generically, any "predicated instruction") tends to
> generally a bad idea
On Wednesday 03 January 2007 17:03, Linus Torvalds wrote:
On Wed, 3 Jan 2007, Grzegorz Kulewski wrote:
Could you explain why CMOV is pointless now? Are there any benchmarks
proving
that?
CMOV (and, more generically, any predicated instruction) tends to
generally a bad idea on an
On Wednesday 03 January 2007 21:38, Linus Torvalds wrote:
On Wed, 3 Jan 2007, Denis Vlasenko wrote:
Why CPU people do not internally convert cmov into jmp,mov pair?
...
It really all boils down to: there's simply no real reason to use cmov.
It's not horrible either, so go ahead and use
On Saturday 30 December 2006 23:08, Robert P. J. Day wrote:
> >
> > clear_page assumes that given address is page aligned, I think. It
> > may fail if you feed it with misaligned region's address.
>
> i don't see how that can be true, given that most of the definitions
> of the clear_page() macro
On Tuesday 26 December 2006 16:18, Tejun Heo wrote:
> Hello, all.
>
> This patchset implements managed device resources, in short, devres.
I was working on a Linux device driver. Indeed, those error paths
are notoriously prone to bugs.
Patchset looks like good idea to me.
--
vda
-
To
1 - 100 of 365 matches
Mail list logo
