headers
Jay Lan | 1 Sep 2004 01:01
Picon

Re: [Lse-tech] Re: [PATCH] new CSA patchset for 2.6.8

Adding csa <at> oss.sgi.com, the CSA user group mailing list, to Cc.

Tim Schmielau wrote:
> On Mon, 30 Aug 2004, Guillaume Thouvenin wrote:
> 
> 
>>  Thus, to be clear, the enhanced accounting can be divided into
>>three parts:
>>
>>    1) A common data collection method in the kernel.
>>       We could start from BSD-accounting and add CSA information. Could
>>       it be something like BSD version4?
> 
> 
> I've had a quick look at the CSA data collection patches. To get the 
> discussion started, here are my comments:
> 
> 
>>--- linux.orig/drivers/block/ll_rw_blk.c        2004-08-13 22:36:16.000000000 -0700
>>+++ linux/drivers/block/ll_rw_blk.c     2004-08-18 12:07:10.000000000 -0700
>> <at>  <at>  -1948,10 +1950,12  <at>  <at> 
>> 
>>        if (rw == READ) {
>>                disk_stat_add(rq->rq_disk, read_sectors, nr_sectors);
>>+               current->rblk += nr_sectors;
>>                if (!new_io)
>>                        disk_stat_inc(rq->rq_disk, read_merges);
>>        } else if (rw == WRITE) {
>>                disk_stat_add(rq->rq_disk, write_sectors, nr_sectors);
>>+               current->wblk += nr_sectors;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christer Weinigel | 1 Sep 2004 01:02
Picon
Favicon

Re: silent semantic changes with reiser4

Linus Torvalds <torvalds <at> osdl.org> writes:

> In a graphical environment, the "icon" stream is a good example of this.  
> It literally has _nothing_ to do with the data in the main stream. The
> only linkage is a totally non-technical one, where the user wanted to
> associate a secondary stream with the main stream _without_ altering the
> main one. THAT is where named streams make sense.

I think that the "icon" argument for named streams is a silly
argument, since different users may want to have different icons for
the same file.  Say that I want /usr/bin/emacs to have the enterprise
icon and someone else wants the gnu head icon.  And besides, root owns
the file anyways, so neither of us mortal users should be able to add
a stream to it.

Another reason for named streams that usually crops up is the ability
set a "preferred application" for a certain file, so that when I
double click on a document I want to open it with antiword instead of
openoffice.  But the same contra-argument applies here, different
users have different preferences.

I can see the argument for having the equivalent of Content-type or
Content-transfer-encoding as a named stream though.

  /Christer

--

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lee Revell | 1 Sep 2004 01:03

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

On Tue, 2004-08-31 at 02:53, Ingo Molnar wrote:
> > > 
> > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk4-Q5
>
> ok. It seems the random driver is _mostly_ in shape latency-wise, except
> the IP rekeying visible in the above trace. To solve this problem, could
> you try the patch below, ontop of -Q5? It moves the random seed
> generation outside of the spinlock - AFAICS the spinlock is only needed
> to protect the IP sequence counter itself.

This solves the problem with the random driver.  The worst latencies I
am seeing are in netif_receive_skb().  With netdev_max_backlog set to 8,
the worst is about 160 usecs:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace2.txt
http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace3.txt

Setting netdev_max_backlog to 1 has no effect:

http://krustophenia.net/testresults.php?dataset=2.6.9-rc1-Q5#/var/www/2.6.9-rc1-Q5/trace4.txt

I would expect this one to scale with CPU speed, so this is pretty good
considering my relatively underpowered system.  I would imagine on a
fast UP system you would not see any latencies worse than 100 usecs.

Lee
Permalink | Reply | 3 comments |
headers
Dave Hansen | 1 Sep 2004 01:12
Picon
Favicon

Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap(2) [1/3]

On Tue, 2004-08-31 at 15:55, Hiroyuki KAMEZAWA wrote:
> Dave Hansen wrote:
> 
> > On Tue, 2004-08-31 at 03:41, Hiroyuki KAMEZAWA wrote:
> > 
> >>+static void __init calculate_aligned_end(struct zone *zone,
> >>+					 unsigned long start_pfn,
> >>+					 int nr_pages)
> > 
> > ...
> > 
> >>+		end_address = (zone->zone_start_pfn + end_idx) << PAGE_SHIFT;
> >>+#ifndef CONFIG_DISCONTIGMEM
> >>+		reserve_bootmem(end_address,PAGE_SIZE);
> >>+#else
> >>+		reserve_bootmem_node(zone->zone_pgdat,end_address,PAGE_SIZE);
> >>+#endif
> >>+	}
> >>+	return;
> >>+}
> > 
> > 
> > What if someone has already reserved that address?  You might not be
> > able to grow the zone, right?
> > 
> 1) If someone has already reserved that address,  it (the page) will not join to
>    buddy allocator and it's no problem.
> 
> 2) No, I can grow the zone.
>    A reserved page is the last page of "not aligned contiguous mem_map", not zone.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andi Kleen | 1 Sep 2004 01:06
Picon
Favicon

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

Ingo Molnar <mingo <at> elte.hu> writes:

> The question is, does any of the Intel (or AMD) docs
> say that the CPU cache has to be write-back flushed when setting MTRRs,
> or were those calls only done out of paranoia?

Both the Intel and AMD docs require the cache flush for MTRR
caching attribute changes. 

At least in pageattr (which is related) i know of cases where
not doing them caused data corruption in real loads.

-Andi
Permalink | Reply | 0 comments |
headers
Andi Kleen | 1 Sep 2004 01:10
Picon
Favicon

Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q5

Ingo Molnar <mingo <at> elte.hu> writes:

> * Ingo Molnar <mingo <at> elte.hu> wrote:
>
>> 
>> * Lee Revell <rlrevell <at> joe-job.com> wrote:
>> 
>> > File under boot-time stuff, I guess.  This could be bad if X crashes,
>> > but I can't remember the last time this happened to me, and I use xorg
>> > CVS.
>> 
>> but the first wbinvd() within prepare_set() seems completely unnecessary
>> - we can flush the cache after disabling the cache just fine.
>
> the third wbinvd() in post_set() seems unnecessary too - what kind of
> cache do we expect to flush, we've disabled caching in the CPU ... But
> the Intel pseudocode does it too - this is a thinko i think.

The multiple steps are needed, otherwise there can be problems
with hyperthreading (the first x86-64 didn't do it in all cases,
and it causes occassional problens with Intel CPUs) 

Also repeated calls of this are relatively cheap because at the
second time there is not much to flush anymore.

I would suggest to not do this change, it could cause very
subtle problems.

-Andi
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christer Weinigel | 1 Sep 2004 01:19
Picon
Favicon

Re: silent semantic changes with reiser4

Pavel Machek <pavel <at> ucw.cz> writes:

> Okay, that does work, it just is not really nice. Just as reserving
> fixed ammount of space for disk cache is bad, reserving fixed ammount
> of space for ccache (and similar) is bad. When there are few of such
> caches, balancing between them starts to matter...

So try to convince them to use the same cache daemon or the same
shared cache manager library then.  It isn't all that different from
implementing a kernel interface that everyone is supposed to use.

A cache manager daemon could sit and watch the free space on the disk
every other second and start deleting the cached files (according to
some LCU heuristics or whatever) whenever free space is getting low.

To see if the original file is newer than the cached file, good old
mtime can be used.  

I can't remember who right now, but someone mentioned a few problems
with timestamps:

1. The resolutions is too low in current kernels, but that just means
   that someone(tm) needs to implement nanosecond timestamps in the
   kernel and for the filesystems.

2. Even nanosecond timestams may become to coarse in the future.  One
   way of getting around this is to keep track of the latest timestamp
   written and make sure the next timestamp is one higher than the
   latest one.  This way timestamps are always increasing, and I doubt
   that we can have modifications each nanosecond for a long time with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Sep 2004 01:01

Re: [2.6 patch] kill __always_inline

Adrian Bunk <bunk <at> fs.tum.de> wrote:
>
> If you want to change inline at some point, you will have to audit all  
> users of inline anyway - so why bother if you don't intend to change 
> inline in the forseeable future?

inline was set to do `always inline' when it was discovered that new gcc
was doing dopey things.  If gcc gets fixed then we don't need that any more.

But functions which *must* be inlined should be marked __always_inline
regardless of anything else.
Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Sep 2004 01:24

Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap(2) [0/3]

Hiroyuki KAMEZAWA <kamezawa.hiroyu <at> jp.fujitsu.com> wrote:
>
> Because I had to record some information about shape of mem_map, I used PG_xxx bit.
> 1 bit is maybe minimum consumption.

The point is that we're running out of bits in page.flags.

You should be able to reuse an existing bit for this application.  PG_lock would suit.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 2 comments |
headers
Nigel Cunningham | 1 Sep 2004 01:12

Re: [2.6 patch] kill __always_inline

Hi.

On Wed, 2004-09-01 at 08:52, Adrian Bunk wrote:
> On Tue, Aug 31, 2004 at 03:36:49PM -0700, Andrew Morton wrote:
> > Adrian Bunk <bunk <at> fs.tum.de> wrote:
> > >
> > > An issue that we already discussed at 2.6.8-rc2-mm2 times:
> > > 
> > > 2.6.9-rc1 includes __always_inline which was formerly in  -mm.
> > > __always_inline doesn't make any sense:
> > > 
> > > __always_inline is _exactly_ the same as __inline__, __inline and inline .
> > > 
> > > 
> > > The patch below removes __always_inline again:
> > 
> > But what happens if we later change `inline' so that it doesn't do
> > the `always inline' thing?
> > 
> > An explicit usage of __always_inline is semantically different than
> > boring old `inline'.

Excuse me if I'm being ignorant, but I thought always_inline was
introduced because with some recent versions of gcc, inline wasn't doing
the job (suspend2, which requires a working inline, was broken by it for
example). That is to say, doesn't the definition of always_inline vary
with the compiler version?

Regards,
(Continue reading)

Permalink | Reply | 5 comments |

Gmane