SKGE Kconfig help text typo fix
SKGE surely isn't a meta driver. Not that this is relevant at all... Signed-off-by: Tim Schmielau <[EMAIL PROTECTED]> --- linux-2.6.13/drivers/net/Kconfig2005-08-29 01:41:01.0 +0200 +++ linux-2.6.13-skge/drivers/net/Kconfig 2005-09-08 10:57:38.0 +0200 @@ -1928,7 +1928,7 @@ config SKGE ---help--- This driver support the Marvell Yukon or SysKonnect SK-98xx/SK-95xx and related Gigabit Ethernet adapters. It is a new smaller driver - driver with better performance and more complete ethtool support. + with better performance and more complete ethtool support. It does not support the link failover and network management features that "portable" vendor supplied sk98lin driver does. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: move-accounting-function-calls-out-of-critical-vm-code-paths.patch
On Thu, 3 Feb 2005, Andrew Morton wrote: > Well your patch certainly cleans things up in there and would be a good > thing to have as long as we can be sure that it doesn't break the > accounting in some subtle way. I think it also fits well with the other accounting data which is only statistically probed at clock ticks. > Which implies that we need to see some additional accounting code, so we > can verify that the base accumulation infrastructure is doing the expected > thing. As well as an ack from the interested parties. Does anyone know > what's happening with all the new accounting initiatives? I'm seeing no > activity at all. Well, I'm here :), but I'm concentrating on making a GNU acct release happen. Anyways, as I'm not involved with memory accounting yet, I guess I should leave it to CSA and ELSA people to comment. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ASUS P2B-DS
> Hi Vise People, > > > ASUS P2B-DS board seems NOT work very well with default kernel in FED > Core 3. smp-kernel hangs booting at various stages. I am goig to try > 2.6.10 today. non-smp-kernel boots fine. This is my first time I try to > test with smp-kernels so I don't know what I could try. Could someone > give me some directions what to test? > > If someone already know this is doomed motherboard might say so I > wouldn't waste time with it. Thanks. P2B-DS is a great, robust mainboard. This mail is written on one, and we have some more in production. Never had any problems with them. Try deleting the OSS sound drivers under /lib/modules/*/kernel/sound/oss/ . While I don't run fedora, I had similar problems with SuSE 9.1 and 9.2. These boiled down to a problem with the el cheapo fm801 soundcard I plugged into the board. The default installation installed an OSS driver that is not SMP-safe. After removing the driver, the correct ALSA driver got selected and everything was fine. Hope this helps Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] "biological parent" pid
The ppid of a process is not really helpful if I want to reconstruct the
real history of processes on a machine, since it may become 1 when the
parent dies and the process is reparented to init.
I am not aware of concepts in Linux or other unices that apply to this
case. So I made up the "biological parent pid" bioppid (in contrast to the
adoptive parents pid) that just never changes.
Any user of it must of course remember that it doesn't need to be a valid
pid anymore or might even belong to a different process that was forked in
the meantime. bioppid only had to be a valid pid at time btime (it's
a (btime, pid) pair that unambiguously identifies a process).
Comments? (other that I just broke /proc/nnn/status parsing once again :-)
Tim
--- linux-2.6.10/include/linux/sched.h 2004-12-24 22:33:59.0 +0100
+++ linux-2.6.10-ppid/include/linux/sched.h 2005-01-31 19:20:00.0
+0100
@@ -556,6 +556,7 @@ struct task_struct {
unsigned did_exec:1;
pid_t pid;
pid_t tgid;
+ pid_t bioppid; /* biological parents */
/*
* pointers to (original) parent process, youngest child, younger
sibling,
* older sibling, respectively. (p->father can be replaced with
--- linux-2.6.10/kernel/fork.c 2004-12-24 22:33:59.0 +0100
+++ linux-2.6.10-ppid/kernel/fork.c 2005-01-31 18:15:39.0 +0100
@@ -889,6 +889,7 @@ static task_t *copy_process(unsigned lon
p->tgid = p->pid;
if (clone_flags & CLONE_THREAD)
p->tgid = current->tgid;
+ p->bioppid = current->pid;
if ((retval = security_task_alloc(p)))
goto bad_fork_cleanup_policy;
--- linux-2.6.10/fs/proc/array.c2004-12-24 22:35:00.0 +0100
+++ linux-2.6.10-ppid/fs/proc/array.c 2005-01-31 18:19:02.0 +0100
@@ -165,6 +165,7 @@ static inline char * task_state(struct t
"Tgid:\t%d\n"
"Pid:\t%d\n"
"PPid:\t%d\n"
+ "BioPPid:\t%d\n"
"TracerPid:\t%d\n"
"Uid:\t%d\t%d\t%d\t%d\n"
"Gid:\t%d\t%d\t%d\t%d\n",
@@ -172,6 +173,7 @@ static inline char * task_state(struct t
(p->sleep_avg/1024)*100/(102000/1024),
p->tgid,
p->pid, pid_alive(p) ? p->group_leader->real_parent->tgid : 0,
+ p->bioppid,
pid_alive(p) && p->ptrace ? p->parent->pid : 0,
p->uid, p->euid, p->suid, p->fsuid,
p->gid, p->egid, p->sgid, p->fsgid);
--- linux-2.6.10/kernel/acct.c 2004-12-24 22:34:58.0 +0100
+++ linux-2.6.10-ppid/kernel/acct.c 2005-01-31 18:19:35.0 +0100
@@ -446,7 +446,7 @@ static void do_acct_process(long exitcod
#endif
#if ACCT_VERSION==3
ac.ac_pid = current->tgid;
- ac.ac_ppid = current->parent->tgid;
+ ac.ac_ppid = current->bioppid;
#endif
read_lock(&tasklist_lock); /* pin current->signal */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] "biological parent" pid
On Mon, 31 Jan 2005, Michael Buesch wrote:
> Quoting Tim Schmielau <[EMAIL PROTECTED]>:
> > The ppid of a process is not really helpful if I want to reconstruct the
> > real history of processes on a machine, since it may become 1 when the
> > parent dies and the process is reparented to init.
> >
> > I am not aware of concepts in Linux or other unices that apply to this
> > case. So I made up the "biological parent pid" bioppid (in contrast to the
> > adoptive parents pid) that just never changes.
> > Any user of it must of course remember that it doesn't need to be a valid
> > pid anymore or might even belong to a different process that was forked in
> > the meantime. bioppid only had to be a valid pid at time btime (it's
> > a (btime, pid) pair that unambiguously identifies a process).
> >
> > Comments? (other that I just broke /proc/nnn/status parsing once again :-)
>
> Eh, I can't see how this bioppid would be useful.
> Help me. Examples?
I'm trying to reconstruct the complete history of processes from the
BSD accounting records. However, this is not very useful if a large
fraction of the processes look as if they were started by init.
The following program will print the history in a form vaguely resembling
pstree output from the accounting file:
Tim
/* treeacct.c: use ac_pid and ac_ppid fields of struct acct_v3 to
* build a tree of the process history.
*
* $Id: treeacct.c,v 0.8 2005/01/31 23:34:51 tim Exp tim $
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define TIME_FUZZ 4
void *alloc(size_t size)
{
void *mem;
mem = malloc(size);
if (mem==NULL) {
fprintf(stderr, "out of memory.\n");
exit(5);
}
return mem;
}
/*
* For each pid the acct records are organized in a singly linked list
* named task_struct that is sorted by process start time (btime).
*
* They also form a tree according to their family relations.
*/
struct task_struct {
/* struct task_struct *prev; seems to be superfluous */
struct task_struct *next, *parent, *children, *siblings;
struct acct_v3 *acct;
};
struct pid_struct {
struct pid_struct *next;
struct task_struct *tasklist;
};
/*
* The task_structs are stored in a hash array of singly linked pid_struct
* lists sorted by pid.
*/
#define PID_HASH_MASK 0xf
struct pid_struct *pid_hash[PID_HASH_MASK + 1];
/*
* List of tasks without parents.
*/
struct task_struct *orphans=NULL;
/*
* Find the task that is uniquely determined by it's pid and the
* time when the pid was valid.
* If create!=0 and the task doesn't exist yet, create it.
*/
struct task_struct *get_task(__u32 pid, __u32 time, int create)
{
struct task_struct **task, *newtask;
struct pid_struct **pidlist, *newpid;
pidlist = &pid_hash[pid & PID_HASH_MASK];
while (*pidlist!=NULL && (*pidlist)->tasklist->acct->ac_pid > pid)
pidlist = &((*pidlist)->next);
if (*pidlist==NULL || (*pidlist)->tasklist->acct->ac_pid < pid) {
/* this pid doesn't exist */
if (create!=0) {
/* so create task */
newtask = alloc(sizeof(struct task_struct));
newtask->next = NULL;
/* as well as a pidlist for it*/
newpid = alloc(sizeof(struct pid_struct));
newpid->next = *pidlist;
newpid->tasklist = newtask;
*pidlist = newpid;
return newtask;
} else {
return NULL;
}
} else {
/* find task on pidlist */
task = &((*pidlist)->tasklist);
while (*task!=NULL
&& (*task)->acct->ac_btime < time)
task = &((*task)->next);
if (*task!=NULL
&& (*task)->acct->ac_btime <= time+TIME_FUZZ
&& (*task)->acct->ac_btime
+ (__u32)((*task)->acct->ac_etime+1)
>= time-TIME_FUZZ) {
/* process found */
if (create!=0) {
fprintf(stderr,
"warning: pid %lu, occurs twice"
" at time $lu.",
pid, time);
} else {
return *task;
Re: [RFC] "biological parent" pid
On Tue, 1 Feb 2005, Helge Hafting wrote: > Tim Schmielau wrote: > > > > >I'm trying to reconstruct the complete history of processes from the > >BSD accounting records. However, this is not very useful if a large > >fraction of the processes look as if they were started by init. > > > >The following program will print the history in a form vaguely resembling > >pstree output from the accounting file: > > > > > Just having those original ppids won't really help you, if the process > is long gone with no trace of what it was. Consider adding logging to > "fork()" and "exec()" instead of doing this. Then you can reconstruct > history all the way back to the correct executables. Why should the process get lost with no trace of what it was - are you questioning reliability of BSD accounting? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] "biological parent" pid
On Tue, 1 Feb 2005, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > I am not aware of concepts in Linux or other unices that apply to this > > case. > > Normal process accounting. Sure. That's what the patch was made for. Or do you have anything else in mind than BSD accounting? > If you want to keep the pid of the bio-parent, you also need to keep the > start-time to make it unique. Yes, that's what I wrote: A process would be uniquely identified by the (btime, pid) pair, in terms of BSD accounting field names. Or (start_time, pid), if we use the names of task_struct members. > Better would be to have a all-time-unqiue process handle. Yes, but that would need new infrastructure. So instead of assigning new 64 bit process handles, we can just just that pair of 32 bit variables. > But I think it is better to not have that field, but use > audit logs. That is especially needed if you want to track chains, because > it doesnt help you to know the bio parent if you have no idea what that was. That's the kind of comment I was actually seeking - maybe what I'm trying is not really worth because anyone interested in its reliability and security would use auditing anyways. But still it might be useful for 'home use', because I do have an idea of what the parent was if I keep the BSD accounting records. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] "biological parent" pid
On Tue, 1 Feb 2005, Bill Davidsen wrote: > Tim Schmielau wrote: > > The ppid of a process is not really helpful if I want to reconstruct the > > real history of processes on a machine, since it may become 1 when the > > parent dies and the process is reparented to init. > > > > I am not aware of concepts in Linux or other unices that apply to this > > case. So I made up the "biological parent pid" bioppid (in contrast to the > > adoptive parents pid) that just never changes. > > Any user of it must of course remember that it doesn't need to be a valid > > pid anymore or might even belong to a different process that was forked in > > the meantime. bioppid only had to be a valid pid at time btime (it's > > a (btime, pid) pair that unambiguously identifies a process). > > I think you are not only using a hammer to swat a fly, buy the wrong > fly. Would it not do as well to log reparenting? You could even add that > as an option to init, although if you are being lazy about tracking the > original parent a kernel log saying something like >reparent PID1 from PID2 to PID3 > would be best. While I think all current reparenting is done to init, I > could certainly think of a use for a method to reparent back to the > grandparent, just to keep the accounting clean. My idea of a hammer seems to be slightly different. After all, I just added _two_lines_ of code [*] to log useful information where useless info was logged before. Any new logging mechanism would be orders of magnitude more expensive. Tim [*] or, in other word, 4 bytes per task_struct and one instruction to fill that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Query - Regarding strange behaviour.
On Thu, 3 Feb 2005, Pankaj Agarwal wrote: > In my system there's a strange behaviour its not allowing me to create > any file in /usr/bin even as root. Its chmod is set to 755. Its even not > allowing me to change the chmod value of /usr/bin. The strangest part which > i felt is ...its shows the owner and group as root when i issue command > "ls -ld /usr/bin" and not allowing root to create any file or directory > under /usr/bin and not even allowing to change the chmod value. The error is > access permission denied... I can change the chmod value of /usr and other > directories under /usr/...but not of bin Maybe /usr is mounted read-only? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: A common layer for Accounting packages
On Tue, 22 Feb 2005, Andrew Morton wrote: > We really want to avoid doing such stuff in-kernel if at all possible, of > course. > > Is it not possible to implement the fork/exec/exit notifications to > userspace so that a daemon can track the process relationships and perform > aggregation based upon individual tasks' accounting? That's what one of > the accounting systems is proposing doing, I believe. > > (In fact, why do we even need the notifications? /bin/ps can work this > stuff out). I had started a proof of concept implementation that could reconstruct the whole process tree from userspace just from the BSD accounting currently in the kernel (+ the conceptual bug-fix that I misnamed "[RFC] "biological parent" pid"). This could do the whole job ID thing from userspace. Unfortunately, I haven't had time to work on it recently. Also, doing per-job accounting might actually be more lightweight than per-process accounting, so I'm not at all opposed to unifying CSA and BSD accounting into one mechanism that just writes different file formats. A complete framework seems like overkill to me, too. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues.
On Fri, 25 Feb 2005, Mark Fortescue wrote: > The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be > correct. I had some errors during patching so I generated a diff against a > freshly downloaded linux-2.6.10 kernel. See the steps below: > > 1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf - > 2) cd linux-2.6.8.1 > 3) bzcat ../patch-2.6.8.1.bz2 | patch -R -p1 > This gives a 2.6.8 kernel. > > 4) bzcat ../patch-2.6.9.bz2 | patch -p1 > This should give a 2.6.9 kernel. The patch has two errors: > ./net/ipv4/netfilter/ipt_ecn.c.rej > ./net/ipv4/netfilter/ipt_tcpmss.c.rej > > 5) bzcat ../patch-2.6.10.bz2 | patch -p1 -f > This should give a 2.6.10 kernel. The patch has three erros: > ./include/linux/netfilter_ipv4/ipt_connmark.h.rej > ./net/ipv4/netfilter/ipt_connmark.c.rej > ./net/ipv6/netfilter/ip6t_MARK.c.rej > 6) cd ..; mv linux-2.6.8.1 linux-2.6.10p > 7) bzcat linux-2.6.10.tar.bz2 | tar -xf - > 8) diff -rupN linux-2.6.10p linux-2.6.10 | tee patch-2.6.10.err Yes, these steps should work. Actually, I just checked (copy & paste the commands from your mail), and it works for me. Are you sure your files are ok? md5sums for my copies of the files are cffcd2919d9c8ef793ce1ac07a440eda linux-2.6.10.tar.bz2 98f93075c7c24e681eaf7e70783af5e4 linux-2.6.8.1.tar.gz 98b7db13a3f13199a48e89a79d2ee388 patch-2.6.10.bz2 824b7d88ab2fabc031f1a6c1e6e288ee patch-2.6.8.1.bz2 fe744cdcd31b97b803e51ad785520489 patch-2.6.9.bz2 Are you sure your filesystem works ok? Not out of quota? Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] connector: Add a fork connector
> > +#ifdef CONFIG_FORK_CONNECTOR
[...]
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
[...]
> > +}
> > +#else
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
> > + return;
> > +}
> > +#endif
[...]
> > @@ -1238,6 +1281,8 @@ long do_fork(unsigned long clone_flags,
> > if (unlikely (current->ptrace &
> > PT_TRACE_VFORK_DONE))
> > ptrace_notify ((PTRACE_EVENT_VFORK_DONE <<
> > 8) | SIGTRAP);
> > }
> > +
> > + fork_connector(current->pid, p->pid);
> > } else {
> > free_pidmap(pid);
> > pid = PTR_ERR(p);
> Guillaume, I see that you are trying to discover if the kernel has
> CONFIG_FORK_CONNECTOR defined or not. In case CONFIG_FORK_CONNECTOR is
> not defined, you will call a "dummy" fork_connector (which just call
> "return"). But why you dont move the checking to where you call
> fork_connector? In this case, if CONFIG_FORK_CONNECTOR is not defined,
> nothing called, and of course you dont need a "dummy" fork_connector
> like in the above code.
>
> Just try something like this:
>
> +#ifdef CONFIG_FORK_CONNECTOR
> +
> + fork_connector(current->pid, p->pid);
> #endif
No, Guillaume did it right. Don't litter the code with useless #ifdefs
that turn one simple line of code into three for no good.
The dummy routine is optimized away by the compiler anyways.
Only the name "fork_connector()" might be discussed...
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.11-rc4-mm1] end-of-proces handling for acct-csa
On Wed, 2 Mar 2005, Guillaume Thouvenin wrote: > Is it possible to merge BSD and CSA? I mean with CSA, there is a part > that does per-process accounting. For exemple in the > linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and > csa_update_integrals() update fields in the current (and parent) > process. So maybe you can improve the BSD per-process accounting or > maybe CSA can replace the BSD per-process accounting? Yes, that was also my preferred direction - make CSA able to also write BSD acct format, and replace the existing BSD accounting with CSA. However it seems this will still increase the amount of kernel code quite a bit. Sorry for not going into any details, I have to leave right now and will be offline for two weeks. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] new timeofday core subsystem (v. A2)
> Monotonic clocks could be calculated > > monotime = ns_at_last_tick + (time_source_cycles_since_tick * > current_scaling_factor) >> shift_factor. > > This would also be easy to implement in asm if necessary. > > tick processing could then increment or decrement the current scaling > factor to minimize the error between ticks. It could also add > nanoseconds to ns_at_last_tick to correct the clock forward. I'd think that adding nanoseconds to ns_at_last_tick is not a good idea. It might minimize the error shortly after the tick, but not the total error average over the whole tick period. And it introduces clock jumps. Tiny, but unnecessary. Just as you say, > With the appropiate shift_factor one should be able to fine tune time much > more accurately than ntp_scale would do. Over time the necessary > corrections could be minimized to just adding a few ns once in a while. finetuning the scaling factor should be enough. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Robert P. J. Day wrote: > Centralize the attribute macro definition of "__packed" so no > subsystem has to do that explicitly. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > --- > > compile tested to make sure the HFS subsystem still builds. now > there's just 50 gazillion usages of "__attribute__((packed))" that can > be tightened up. > > > fs/hfs/hfs.h |2 -- > fs/hfsplus/hfsplus_raw.h |2 -- > include/linux/compiler-gcc.h |1 + > 3 files changed, 1 insertion(+), 4 deletions(-) Moving definitions into compiler-gcc.h only will screw non-gcc compilers like icc. They should probably go into the generic section of compiler.h instead. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Centralize the macro definition of "__packed".
On Thu, 18 Jan 2007, Robert P. J. Day wrote: > actually, it *appears* that the standard works this way. the macro > "__deprecated" is defined in compiler-gcc.h with: > > #define __deprecated __attribute__((deprecated)) > > while the more generic compiler.h handles whether or not it was > defined: > > #ifndef __deprecated > # define __deprecated /* unimplemented */ > #endif > > so i'm guessing that's how any new attribute shortcut macros should be > handled, yes? Well, since the definitions lived well in compiler-generic land for quite some time, I'd guess it should be ok not to #ifndef - guard them. likely() and unlikely() are currently handled like that. If the need ever arises to make them compiler specific, whoever does that can still add the #ifndef then. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal disk performance, how to debug?
On Sat, 20 Jan 2007, Ismail Dönmez wrote: > 20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız: > [...] > > > vaio cartman # hdparm -tT /dev/hda > > > > > > /dev/hda: > > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec > > > Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec > > > > > > > > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 > > > 1024+0 records in > > > 1024+0 records out > > > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s > > > > > > real1m17.482s > > > user0m0.003s > > > sys 0m2.350s > > > > That's not bad at all ! I suspect that if your system becomes unresponsive, > > it's because real writes start when the cache is full. And if you fill > > 512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it > > can take about 40 seconds during which it might be difficult to do > > anything. > > > > Try lowering the cache flush starting point to about 10 MB if you want > > (2% of 512 MB) : > > > > # echo 2 >/proc/sys/vm/dirty_ratio > > # echo 2 >/proc/sys/vm/dirty_background_ratio > > After that I get, > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s > > real0m41.926s > user0m0.007s > sys 0m2.500s > > > not bad! thanks :) Note that these dd "benchmarks" are completely bogus, because the data doesn't actually get written to disk in that time. For some enlightening data, try time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync The dd returns as soon as all data could be buffered in RAM. Only sync will show how long it takes to actually write out the data to disk. also explains why you see better results is writeout starts earlier. Tim
Re: Abysmal disk performance, how to debug?
On Sat, 20 Jan 2007, Ismail Dönmez wrote: > 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı: > > > > Note that these dd "benchmarks" are completely bogus, because the data=20 > > doesn't actually get written to disk in that time. For some enlightening=20 > > data, try > > > > time dd if=3D/dev/zero of=3D/tmp/1GB bs=3D1M count=3D1024; time sync > > > > The dd returns as soon as all data could be buffered in RAM. Only sync=20 > > will show how long it takes to actually write out the data to disk. > > also explains why you see better results is writeout starts earlier. > > Still not that bad: > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024;sync > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1,1 GB) copied, 53,3194 s, 20,1 MB/s > > real0m53.517s > user0m0.003s > sys 0m3.193s > That's not the point, you still measured the same as before (but you might have noticed that, after printing the results, the shell prompt took some time to appear). I appended "time sync" to the command to show that (depending on the amount of available memory) actually most of the time is spent in the "sync", not the "dd". Tim
Re: Abysmal disk performance, how to debug?
On Sat, 20 Jan 2007, Willy Tarreau wrote: > Anyway, in your situation with a very small buffer, this should not > change by more than half a second or so. Well, his buffer is not small. He has half a GB of RAM, so when writing 1 GB the buffer would roughly double the dd speed, exactly as he has shown us. Anyways, instead of always just posting similar answers to yours, I'll have dinner now. :-) Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal disk performance, how to debug?
On Sat, 20 Jan 2007, Willy Tarreau wrote: > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote: > > > > Note that these dd "benchmarks" are completely bogus, because the data > > doesn't actually get written to disk in that time. For some enlightening > > data, try > > > > time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync > > > > The dd returns as soon as all data could be buffered in RAM. Only sync > > will show how long it takes to actually write out the data to disk. > > While I 100% agree with you on this, I'd like to note that I don't agree > with the following statement : > > > also explains why you see better results is writeout starts earlier. > > The results should be better when writeout starts later since most of > the transfer will have been performed at RAM speed. That's what happens > with the user above with 2 GB RAM. But in case of the VAIO with 512 MB, > there's really something strange IMHO. I suspect it has two RAM areas, > one fast and one slow (probably one two large non-cacheable area for a > shared video or such a crap, which can be avoided when reducing the > cache size). No - the earlier the writeout starts, the earlier he will have enough free RAM to finish the dd command by buffering the remaining data. Note that we did not cap the amount of buffers, just started to write out earlier. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal disk performance, how to debug?
On Sat, 20 Jan 2007, Willy Tarreau wrote: > On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote: > > On Sat, 20 Jan 2007, Willy Tarreau wrote: > > > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote: > > > > > > > also explains why you see better results is writeout starts earlier. > > > > > > The results should be better when writeout starts later since most of > > > the transfer will have been performed at RAM speed. That's what happens > > > with the user above with 2 GB RAM. But in case of the VAIO with 512 MB, > > > there's really something strange IMHO. I suspect it has two RAM areas, > > > one fast and one slow (probably one two large non-cacheable area for a > > > shared video or such a crap, which can be avoided when reducing the > > > cache size). > > > > No - the earlier the writeout starts, the earlier he will have enough free > > RAM to finish the dd command by buffering the remaining data. > > OK I see your point. While trying to show why I got you wrong, I in fact > demonstrated to myself that you were right :-) > > For instance, let's say we have 500 MB cache at 1000 MB/s and a write out > threshold of 80% with a disk at 100 MB/s. Writing 1000 MB would produce > this pattern : > > time data sent writtendirty data > in secfrom ddto disk in cache >0.00 MB0 MB0 MB >0.4 400 MB0 MB 400 MB -> writeout starts >1.0 560 MB 60 MB 500 MB >5.4 1000 MB 500 MB 500 MB -> dd leaves. > 10.4 1000 MB 1000 MB0 MB -> write terminated. > > -> avg dd speed = 1000/5.4 = 185 MB/s >avg disk speed = 1000/10.4 = 96 MB/s > > > Now with a lower writeout threshold of 2% (10 MB) : > > time data sent writtendirty data > in secfrom ddto disk in cache >0.00 MB0 MB0 MB >0.01 10 MB0 MB 10 MB -> writeout starts >1.0 599 MB 99 MB 500 MB > 5.01 1000 MB 500 MB 500 MB -> dd leaves. > 10.01 1000 MB 1000 MB0 MB -> write terminated. > > -> avg dd speed = 1000/5.01 = 199.6 MB/s >avg disk speed = 1000/10.01 = 99.9 MB/s > > At least, numbers are not that much different to justify a one to two speed > ratio on the VAIO. The difference being caused by cache speed, it's clearly > possible that his RAM is definitely very very slow which would then explain > the difference. > > > > Note that we did not cap the amount of buffers, just started to write out > > earlier. > > > Indeed, that's what makes the whole difference. I was used to cap the amount > of buffers, but the behaviour here is different. > > Thanks for your insight ! Thanks for being so humble in pointing out my logic is flawed. While the Vaio certainly cannot write 1000GB/s to its RAM, it's disk is also quite slow and the ratio of 10:1 for RAM:disk speed is presumably correct. So we don't quite understand why dd in RAM is so slow for him. Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Abysmal disk performance, how to debug?
On Sun, 21 Jan 2007, Sunil Naidu wrote: > On 1/21/07, Tim Schmielau <[EMAIL PROTECTED]> wrote: > > > > Note that these dd "benchmarks" are completely bogus, because the data > > doesn't actually get written to disk in that time. For some enlightening > > data, try > > > > time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time sync > > > > The dd returns as soon as all data could be buffered in RAM. Only sync > > will show how long it takes to actually write out the data to disk. > > also explains why you see better results is writeout starts earlier. > > I am still getting better I feel: Yes. You have a faster Disk that writes about 45 MB/s. But I am not sure I understand what you want to know? > [EMAIL PROTECTED] ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024; time > sync > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1.1 GB) copied, 19.5007 seconds, 55.1 MB/s > > real0m20.439s > user0m0.004s > sys 0m4.535s > > real0m4.625s > user0m0.000s > sys 0m0.125s > > > [EMAIL PROTECTED] ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024 | sync > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1.1 GB) copied, 20.8707 seconds, 51.4 MB/s > > real0m22.449s > user0m0.002s > sys 0m4.922s > > > Linux used here is not 2.6.20-rc5, but it's a FC6 2.6.19 binary. Shall > post the results with 2.6.20-rc5. > > BTW, does the results vary with a customized kernel (configured w.r.t > Processor & Hardware) than a generic kernel like FC6? I'd guess the kernel won't make much of a difference as the time is mostly determined by RAM and disk speeds. > Are there any other such test cases? Well, what do you want to find out? Anyways, I am in no way expert in the field of benchmarking. Note to Willy: I finally noticed my logic actually was not flawed. I stated why dd would report approximately doubled throughputs with buffering, while you argued why the total elapsed time would not change much. Time to go to bed now... Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove 556 unneeded #includes of sched.h
After Al Viro (finally) succeeded in removing the sched.h #include in module.h recently, it makes sense again to remove other superfluous sched.h includes. To ease the pain, this time I did not fiddle with any header files and only removed #includes from .c-files, which tend to cause less trouble. Also I left alone anything else that looked like any trouble, like hunks that didn't apply cleanly against both mainline and -mm trees. You see, I'd really like to get the patch through this time. Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on x86_64. I also checked that no new warnings were introduced by the patch (actually, some warnings are removed that were emitted by unnecessarily included header files). Signed-off-by: Tim Schmielau <[EMAIL PROTECTED]> Patch attached as .bz2 due to it's size (160k uncompressed). remove-556-unneeded-includes-of-schedh.patch.bz2 Description: BZip2 compressed data
Re: [PATCH] remove 556 unneeded #includes of sched.h
After fiddling with this patch for so long, I forgot to mention an important thing: This time the patch only includes things that need no fixups at all (most of these already went in last time). So all hunks are independent, and you can just drop anything that does not apply or causes any other trouble. Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Andrew Morton wrote: > On Thu, 28 Dec 2006 21:27:40 +0100 (CET) > Tim Schmielau <[EMAIL PROTECTED]> wrote: > > > After Al Viro (finally) succeeded in removing the sched.h #include in > > module.h recently, it makes sense again to remove other superfluous > > sched.h includes. > > Why are they "superfluous"? Because those compilation > units pick up sched.h indirectly, via other includes? > > If so, is that a thing we want to do? No, there is nothing at all in these files that needs sched.h. I suppose the includes are left over from times when more unrelated macros lived in sched.h (fortunately much of that cruft got cleand up already). Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Randy Dunlap wrote: > I'm half done with a patch to remove includes of smp_lock.h. > For the files that I have patched, I checked each source file > for all interfaces in smp_lock.h to verify that none of them > are used, so the #include is just waste. Yes, that's what I also did. And then I checked for all interfaces in all headers included indirectly through sched.h and not already included in the respective source file to see whether any of these includes are needed to keep the file compilable (although this time, amazingly few includes had to be added back - only 5 for all 556) Maybe I should have taken a look at my original patch descripions from last year, I admit the current one isn't very illuminating. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Al Viro wrote: > Uh-huh. How much of build coverage have you got with it? Well, as said in the patch description, I compiled alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on x86_64. I also checked that no new warnings were introduced by the patch. > Note that "doesn't use symbols defined in sched.h" != "can remove > include of sched.h", which, in turn, is not the same as "removing it > doesn't cause problems on a couple of configs I've tried on amd64". Sure. But from my experience (I started posting these patches almost five years ago, inspired by a blog entry by davej) actually the only thing that prevents removing the sched.h include (other than using symbols defined there) is dereferencing current, which my scripts also check. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Russell King wrote: > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig, > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc... OK, I'll try to do that. Do I need to build all the configs in arch/arm/configs? > The whole "all*config" idea on ARM is utterly useless - you can _not_ > get build coverage that way. Or shall I exclude the arm specific drivers for now? Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Russell King wrote: > Given that it takes about 8 to 12 hours to do a build cycle, that's My build cycle takes about 2 hours for 4 configs, on a decent AMD64 system (running completely in tmpfs). Am I doing something wrong or are you talking about native builds? Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Russell King wrote: > I'm talking about cross-builds... I don't know the spec of the machine, > only that it's x86 based (I don't run it.) > > The last report at the beginning of this month said: 11 1/2 hours per > git snapshot, which is apparantly for building a total of about 115 > kernels covering all ARM defconfigs, MIPS, PPC, and i386. Ah, that sound reassuring: 115 kernels in 11.5 hours = 6 minutes per kernel. I just started building all arm defconfigs, and assabet_defconfig took about 7 minutes. So I don't seem to be that far off. Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Randy Dunlap wrote: > On Thu, 28 Dec 2006 21:48:30 + Russell King wrote: > > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote: > > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote: > > > > The whole "all*config" idea on ARM is utterly useless - you can _not_ > > > > get build coverage that way. > > > > > > Uh, can J. Random Developer submit patches to the ARM build system > > > for testing? > > > > Given that it takes about 8 to 12 hours to do a build cycle, that's > > not practical. The only real solution is for us to accept that > > breakage will occur (and be prepared to keep a steady stream of > > fixes heading into Linus' tree - which has been ruled out by Linus) > > or J. Random Developer has to build a set of affected ARM defconfigs > > themselves. > > I guess I don't get it. Isn't that what we just went thru > with the struct nightmare^W work_struct changes? > But these header file changes are much simpler and more obvious... Well, I think it's practical to build all arm configs yourself. I'll do that for my sched.h #include changes. It's been less that two hours since I started the builds on two cpus and I already got 35 out of 59 configs. It's just that one has to be aware of it. Before Russell's post the situation on arm seemed so confusing to me that I thought I'd just compile allnoconfig, defconfig, allmodconfig and allyesconfig and let the arm people figure out the rest. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[updated PATCH] remove 555 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Tim Schmielau wrote: > On Thu, 28 Dec 2006, Russell King wrote: > > > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig, > > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc... > > OK, I'll try to do that. > Do I need to build all the configs in arch/arm/configs? OK, building 2.6.20-rc2-mm1 with all 59 configs from arch/arm/configs with and w/o the patch indeed found one mysterious #include that may not be removed. Thanks, Russell! Andrew, please use the attached patch instead of the previous one, it also has a slightly better patch description. Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove 556 unneeded #includes of sched.h
On Thu, 28 Dec 2006, Randy Dunlap wrote: > Yep, right, if I already had all of that cross-build stuff setup, > it wouldn't be a big deal. But getting it all setup is a big deal > (to me). Well, I didn't want to say that you specifically should do that. ;-) OTOH, if you are interested, setting it up isn't nearly as difficult as it seems. http://kegel.com/crosstool/ almost makes it a no-brainer. It's some years ago that I set up mine, but if you want I'll write up a mini-howto about my setup. Al Viro also deschribed his setup: http://lkml.org/lkml/2004/10/28/17 (and if you are frightened by the braindamage of my sched-removal-tools: no, crosscompiling is nowhere as complicated as that.) Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [updated PATCH] remove 555 unneeded #includes of sched.h
On Fri, 29 Dec 2006, Tim Schmielau wrote: > Andrew, please use the attached patch instead of the previous one, it also > has a slightly better patch description. This time I actually attached something. Sorry. (In case anybody wonders: yes, I did get some sleep while the builds were running) Tim remove-555-unneeded-includes-of-schedh.patch.bz2 Description: BZip2 compressed data
Re: kernel + gcc 4.1 = several problems
Well, on a P4 (which is supposed to be soo bad) I get: > gcc -O2 t.c -o t > foreach x ( 1 2 3 4 5 ) >> time ./t > /dev/null >> end 0.196u 0.004s 0:00.19 100.0%0+0k 0+0io 0pf+0w 0.168u 0.004s 0:00.16 100.0%0+0k 0+0io 0pf+0w 0.168u 0.000s 0:00.16 100.0%0+0k 0+0io 0pf+0w 0.160u 0.000s 0:00.15 106.6%0+0k 0+0io 0pf+0w 0.180u 0.000s 0:00.18 100.0%0+0k 0+0io 0pf+0w > gcc -DCMOV -O2 t.c -o t > foreach x ( 1 2 3 4 5 ) >> time ./t > /dev/null >> end 0.168u 0.000s 0:00.17 94.1% 0+0k 0+0io 0pf+0w 0.152u 0.000s 0:00.15 100.0%0+0k 0+0io 0pf+0w 0.136u 0.004s 0:00.13 100.0%0+0k 0+0io 0pf+0w 0.168u 0.000s 0:00.16 100.0%0+0k 0+0io 0pf+0w 0.172u 0.000s 0:00.17 100.0%0+0k 0+0io 0pf+0w see? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] udivdi3: 64 bit divide
On Tue, 27 Feb 2007, Andrew Morton wrote: > > On Mon, 26 Feb 2007 17:35:17 -0800 Stephen Hemminger <[EMAIL PROTECTED]> > > wrote: > > The kernel already has several implmentations and usages of 64 by 64 > > bit divide. > > > > Although it is significantly slower, there are places that need it so > > provide one generic version using scaling, and allow existing platform > > versions to continue. > > The reason we implement 64/32 via do_div() is, for better or for worse, to > make people think before they use it. And to make it stand out, and so > that we discover places that are using it by accident, where they could use > something cheaper. IMHO it is even more important that the user of your 64/64 div is aware that it only returns an approximate result. I certainly don't want to have any code in the kernel that by accident makes an allocation a few bytes short of the actual size of the object (just to make up a drastic example). Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/time/clocksource.c needs struct task_struct on m68k
On Sun, 4 Feb 2007, Mathieu Desnoyers wrote: > kernel/time/clocksource.c needs struct task_struct on m68k. > > Because it uses spin_unlock_irq(), which, on m68k, uses hardirq_count(), which > uses preempt_count(), which needs to dereference struct task_struct, we > have to include sched.h. Because it would cause a loop inclusion, we > cannot include sched.h in any other of asm-m68k/system.h, > linux/thread_info.h, linux/hardirq.h, which leaves this ugly include in > a C file as the only simple solution. This indeed sounds quite ugly. If there really is no other simple way to resolve this, this case seems to provide the missing incentive to create a task_struct.h header file. Unfortunately, I currently cannot foresee when I will have time to do so. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Measuring cpu time using getrusage
On Wed, 14 Feb 2007, Johann Schuster wrote: > currently i'm trying to measure the cpu times for > numerical algorithms written in C using two calls of > getrusage() and then calculating the time difference. > > According to the man page of getrusage i looked at the > user time of my process. Surprisingly the measured user > times vary strongly depending on the system load of the > machine. > A heavy system load nearly doubles the measured time > for my routine. Does your system have hyperthreading? (look at whether the siblings field in /proc/cpuinfo is greater than one) If yes, there is no way to accurately measure runtimes because the (single-threaded) performance of your CPU depends on the other tasks running. Just disable hyperthreading for these measurements. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Move include linux/marker.h to kernel.h
On Fri, 16 Feb 2007, Andrew Morton wrote: > No, that's still crufty. There's no reason why marker.h needs special > treatment whereas, say, jiffies.h does not (is there?) Unforunately, even jiffies.h gets special treatment. sched.h still includes jiffies.h, as this is where it was originally defined. I've had that on my to-do list for some years now, but unfortunately it will probably remain there for some more. Somebody else who wants to check all files for properly including jiffies.h and then remove the include from sched.h? Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sed _s_gnu_alternatives_ (Re: [rft] (g)awk substitution)
On Fri, 26 Jan 2007, Oleg Verych wrote: > In Debian's version it has no `bc', while native `bc' is producing > crap like that: > ,-*- bash -*- > |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo > |18446744073709551615 > |[EMAIL PROTECTED]:~$ echo -1 | bc > |-1 > |[EMAIL PROTECTED]:~$ printf "%u" $(( 0xFF )) ; echo > |255 > |[EMAIL PROTECTED]:~$ echo FF | bc > |99 > |[EMAIL PROTECTED]:~$ echo F | bc > |15 > |[EMAIL PROTECTED]:~$ > `-*- > > i can't understand the result... I think linux/scripts/makelst may be > updated to have sh's version of address calculation ;) No, IMHO that should not be a reason to change anything in the kernel. Just set ibase=16 or read the fine manual: info '(bc)About Expressions and Special Variables' Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: 2.6.15 Process accounting fails to account for small time slice loads (still)
On Tue, 30 Jan 2007, Tom Burns wrote: > The bug described back in 2004 in the following message still seems to exist: > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html > > Essentially, it appears that if a process sleeps before it uses up a > complete jiffy then no charge is made to its process accounting table. That's not a bug, it's a feature. ;-) More seriously, it's a design decision. The benefit of exactly correct micro bookkeeping does not seem to warrant the extra cost in terms of cpu cycles spent in the accounting code. IIRC there was a patch for that some years ago, if you are interested I will try to find it. No idea how much work it would be to port it to current kernels, though. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: 2.6.15 Process accounting fails to account for small time slice loads (still)
On Tue, 30 Jan 2007, Tom Burns wrote: > That would be great if you could find that patch - I can worry about > porting it to the current kernel. We're having an issue where our > device, while routing large amounts of network traffic, reports 0% CPU > utilisation when it cannot be the case, and I think this is the cause. Here is one patch for CPU cycle accounting: (although I'm not sure that's really the one I had in mind) http://lkml.org/lkml/2004/6/23/78 It might also be worth having a look at oprofile: http://oprofile.sourceforge.net/ If you are on IA64 or PPC rather than i386, ppacc might help you: http://lkml.org/lkml/2006/1/13/308 http://ppacc.sourceforge.net/about.html Although I'd guess you are not on PPC or S390 as these already to correct CPU cycle accounting (IIRC). Hope that helps, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add "is_power_of_2" checking to log2.h.
On Thu, 1 Feb 2007, David Howells wrote: > Robert P. J. Day <[EMAIL PROTECTED]> wrote: > > > +#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1)) > > If this is such a commonly implemented op, it should probably be implemented > globally too. > > I also wonder if there's some better way of implementing it than this, but I > can't think of one offhand. #define is_power_of_2_or_zero(x) ((x & (x-1))==0) #define is_power_of_4(x) (is_power_of_2_or_zero(x) \ && (x & ((typeof(x))0x))) ? Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add "is_power_of_2" checking to log2.h.
On Thu, 1 Feb 2007, [EMAIL PROTECTED] wrote: > On Thu, 01 Feb 2007 13:39:15 +0100, Tim Schmielau said: > > #define is_power_of_4(x) (is_power_of_2_or_zero(x) \ > > && (x & ((typeof(x))0x))) > > Those 5's are going to need more magic if x is a 64-bit typeof? Yeah, I can't count. Make that #define is_power_of_2_or_zero(x) ((x & (x-1))==0) #define is_power_of_4(x) (is_power_of_2_or_zero(x) \ && (x & ((typeof(x))0xull))) of course. Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A CodingStyle suggestion
On Sun, 4 Feb 2007, Ahmed S. Darwish wrote:
> On Sat, Feb 03, 2007 at 11:56:16PM +0100, Richard Knutsson wrote:
> > So:
> >
> > if (is_true()) {
> > /* do something */
> > }
> >
> > is alright then? If so, I agree, but please make it real clear in the
> > document ;)
>
> Good catch :). A small grep of `access_ok' reveals that it's always used in
> the
> form of:
> if (!access_ok()) { .. }
>
> I can conclude that verbal/imperative methods like `kmalloc, add_work' be
> checked as:
> ret = do_work();
> if (ret) { ... }
> and predicate methods like `acess_ok, pci_dev_present' be checked like:
> if (!access_ok) { ... }
> if (pci_dev_present) { ...}
Maybe say that any functions with a side effect should be called on a line
by themselves?
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: la la la la ... swappiness
On Sun, 3 Dec 2006, Aucoin wrote: > during tar extraction ... inactive pages reaches levels as high as ~375000 So why do you want the system to swap _less_? You need to find some free memory for the additional processes to run in, and you have lots of inactive pages, so I think you want to swap out _more_ pages. I'd suggest to temporarily add a swapfile before you update your system. This can even help in bringing your memory use to the state before if you do it like this - swapon additional swapfile - update your database software - swapoff swap partition - swapon swap partition - swapoff additional swapfile Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: la la la la ... swappiness
On Mon, 4 Dec 2006, Aucoin wrote: > > From: Horst H. von Brand [mailto:[EMAIL PROTECTED] > > That means that there isn't a need for that memory at all (and so they > > In the current isolated non-production, not actually bearing a load test > case yes. But if I can't get it to not swap on an idle system I have no hope > of avoiding OOM on a loaded system. I don't think that assumption is correct. If you have no load on your system and the pages in the shared application cache are not actually touched, it is perfectly reasonable for the kernel to push out these unused pages to swap space to have even more RAM available (e.g. for caching the pages more recently accessed by the tar and patch commands). I believe your OOM problem is not connected to these observations. There might be a problem in the handling of OOM situations in Linux. But before coming to that conclusion, I would suggest trying your simulated software upgrade scenario with plenty of swap space available and without playing any tricks with MM settings. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: why are some of my patches being credited to other "authors"?
> but it still leaves an open issue -- once one submits a patch, is there > *any* official feedback that one can look for to see if it's been > accepted/rejected/dropped on the floor/whatever? You can regularely pull Linus' tree (or the tree of the maintainer you sent your patch) and see whether your patches still apply cleanly. Whenever they cause a reject, they need your attention: either they were applied, or they got out of date because something else changed. (akpm also sends out automatic notification emails for patches in the -mm tree based on a similar method.) > but given that i'm trying to follow the kernel guidelines and keep > each submission as a logically-related chunk, in many cases, i have to > wait for one patch to be applied before i can submit the next one. > and, at the moment, there's no way of knowing what's going on. Well, you can send out a patch series: [patch 01/02] Prepare foo for blah [patch 02/02] Apply blah to foo Ideally you would finish the patch description for patch 02 with something like --- This patch depends on [patch 01/02] Prepare foo for blah But usually people will assume they have to apply the patches in order even without you explicitly telling them. Unless you are keen on particular feedback about patch 01 before doing much work on patch 02, this should work out well. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lots of code could be simplified by using ARRAY_SIZE()
On Fri, 15 Dec 2006, Robert P. J. Day wrote: > On Fri, 15 Dec 2006, Jan Engelhardt wrote: > > Even sizeof a / sizeof *a > > > > may happen. > > yes, sadly, there are a number of those as well. back to the drawing > board. It might be interesting to grep for anything that divides two sizeofs and eyeball the result for possible mistakes. This would provide some real benefit beyond the cosmetical changes. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lots of code could be simplified by using ARRAY_SIZE()
On Sat, 16 Dec 2006, Robert P. J. Day wrote: > On Fri, 15 Dec 2006, Tim Schmielau wrote: > > > > It might be interesting to grep for anything that divides two > > sizeofs and eyeball the result for possible mistakes. This would > > provide some real benefit beyond the cosmetical changes. > > i did that a while ago and it's amazing the variation that you find > beyond the obvious: > > $ grep -Er "sizeof.*/.*sizeof" . | less > > ... > ./net/key/af_key.c: sa->sadb_sa_len = sizeof(struct > sadb_sa)/sizeof(uint64_t); > ./net/xfrm/xfrm_policy.c: int len = sizeof(struct xfrm_selector) / > sizeof(u32); > ./net/core/flow.c: const int n_elem = sizeof(struct flowi) / > sizeof(flow_compare_t); > ./net/ipv4/netfilter/arp_tables.c: for (i = 0; i < > sizeof(*arp)/sizeof(__u32); i++) > ./net/ipv4/af_inet.c:#define INETSW_ARRAY_LEN (sizeof(inetsw_array) / > sizeof(struct inet_protosw)) > ./drivers/net/wireless/ray_cs.c:.num_standard = > sizeof(ray_handler)/sizeof(iw_handler), > Of the above, af_inet.c and ray_cs.c seem to be good candidates for ARRAY_SIZE. You might even remove the INETSW_ARRAY_LEN #define in af_inet.c altogether, since ARRAY_SIZE(inetsw_array) is quite readable. xfrm_policy.c, flow.c and arp_tables.c seem to be reasonably readable trickery that can be left as-is. >From a first glance, af_key.c is ok but might profit from a comment in include/linux/pfkeyv2.h saying that sadb_msg_len is measured in 64-bit words per RFC 2367. Though documenting the structs in pfkeyv2.h would be quite a bit different from what you initially intended... So, if you have some time to spend on this, manual inspection would probably be the most useful thing, since any automatic sed tricks will only replace what a human ready would easily understand as well. If you manually generate cleanup patches, it would be very good to check that compilation with allyesconfig generates identical code before and after before feeding them through the respective maintainers. If you want to find genuine bugs by this, it might be more worthwhile to start with drivers/, as davem is just too clever to make any mistakes. Not that I want to make you spend you time on this. It's just beause you asked. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KORG] Re: kernel.org lies about latest -mm kernel
On Sat, 16 Dec 2006, J.H. wrote: > - Gitweb is causing us no end of headache, Is there any mirror for http://git.kernel.org/git/ other than git2.kernel.org? If there is, it would probably help to make it better known. thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3-mm1
On Fri, 5 Jan 2007, Mariusz Kozlowski wrote: > Doesn't build on my iMac G3 based garage jukebox ;-) > > arch/powerpc/kernel/of_platform.c:479: error: unknown field > 'multithread_probe' specified in initializer > arch/powerpc/kernel/of_platform.c:479: warning: initialization makes pointer > from integer without a cast > make[1]: *** [arch/powerpc/kernel/of_platform.o] Blad 1 > make: *** [arch/powerpc/kernel] Blad 2 Can you please post your .config? Thanks, Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression? hdparm shows 1/2...1/3 the throughput
On Sat, 6 Jan 2007, Stefan Richter wrote: > Did anybody else notice this? The result of "hdparm -t" under 2.6.20-rc > seems to be less than half of what you get on 2.6.19. However, disk I/O > did *not* get slower according to bonnie++. yes. See http://lkml.org/lkml/2007/1/2/75 for the solution. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] severing module.h->sched.h
On Wed, 10 Jan 2007, Geert Uytterhoeven wrote: > which needs the definition of struct task_struct. > > The patch below fixes it by including in > kernel/time/clocksource.c. But perhaps this is the right time to move > struct task_struct to its own include instead? I used to post such a patch once every few years, as it allows to remove the (indirect) include of that sched.h monster from a few thousand files. If there is interest in such a move, I'll cook up a patch within the next weeks. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: please pull from the trivial tree
> Chase Venters (1):
> Fix jiffies.h comment
This one actually obscures the comment rather than fixing it.
>From jiffies.h:
> 76 /*
> 77 * The 64-bit value is not volatile - you MUST NOT read it
> 78 * without sampling the sequence number in xtime_lock.
> 79 * get_jiffies_64() will do this for you as appropriate.
> 80 */
> 81 extern u64 __jiffy_data jiffies_64;
> 82 extern unsigned long volatile __jiffy_data jiffies;
Note that jiffies is volatile, while jiffies_64 is not; the comment
currently explains that. The proposed patch
> Fix jiffies.h comment
> jiffies.h includes a comment informing that jiffies_64 must be read with the
> assistance of the xtime_lock seqlock. The comment text, however, calls
> jiffies_64 "not volatile", which should probably read "not atomic".
>
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -74,7 +74,7 @@
> #define __jiffy_data __attribute__((section(".data")))
> /*
> - * The 64-bit value is not volatile - you MUST NOT read it
> + * The 64-bit value is not atomic - you MUST NOT read it
> * without sampling the sequence number in xtime_lock.
> * get_jiffies_64() will do this for you as appropriate.
> */
would leave a comment that is correct, but less useful (I'd expect any
kernel hacker to know that u64 is non-atomic on many platforms).
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: please pull from the trivial tree
On Fri, 1 Dec 2006, Adrian Bunk wrote: > On Fri, Dec 01, 2006 at 01:41:18PM +0100, Tim Schmielau wrote: [...] > > would leave a comment that is correct, but less useful (I'd expect any > > kernel hacker to know that u64 is non-atomic on many platforms). > > > If kernel hackers are expected to already know it's non-atomic we could > remove the whole comment. > > The comment regarding "volatile" was bogus since "volatile" wouldn't > help against getting garbage when reading an u64 variable. Well, it's probably too trivial to argue about anyways - I don't mind much in either direction. Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
