4g/4g for 2.6.6

4g/4g for 2.6.6

[Phy Prabab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 546 bytes --]

Hello,

Please cc me as I am not on this mailling list.

I have been researching the 4g patches for kernels. 
Seems there was a rift between people over this.  Is
there any plan to resume publishing 4g patches for
developing kernels?

I am currently trying to get 4g to work with 2.6.6-mm5
but of course running into issues,so any help on this
would be great!

Thank you for your time.
Phy


	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: 4g/4g for 2.6.6

[Linus Torvalds]

On Sun, 23 May 2004, Phy Prabab wrote:
> 
> I have been researching the 4g patches for kernels. 
> Seems there was a rift between people over this.  Is
> there any plan to resume publishing 4g patches for
> developing kernels?

Quite frankly, a number of us are hoping that we can make them
unnecessary. The cost of the 4g/4g split is absolutely _huge_ on some
things, including basic stuff like kernel compiles.

The only valid reason for the 4g split is that the VM doesn't always 
behave well with huge amounts of highmem. The anonvma stuff in 2.6.7-pre1 
is hoped to make that much less of an issue.

Personally, if we never need to merge 4g for real, I'll be really really 
happy. I see it as a huge ugly hack.

			Linus

Re: 4g/4g for 2.6.6

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Sun, 23 May 2004, Phy Prabab wrote:
> 
>>I have been researching the 4g patches for kernels. 
>>Seems there was a rift between people over this.  Is
>>there any plan to resume publishing 4g patches for
>>developing kernels?
> 
> 
> Quite frankly, a number of us are hoping that we can make them
> unnecessary. The cost of the 4g/4g split is absolutely _huge_ on some
> things, including basic stuff like kernel compiles.


Sorta like I'm hoping that cheap and prevalent 64-bit CPUs make PAE36 
and PAE40 on ia32 largely unnecessary.  Addressing more memory than 32 
bits of memory on a 32-bit CPU always seemed like a hack to me, and a 
source of bugs and lost performance...

	Jeff

Re: 4g/4g for 2.6.6

[Phy Prabab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1186 bytes --]

So do I understand this correctly, in 2.6.7(+) it will
no longer be necessary to have the 4g patches?  I will
be able to get 4g/process with the going forward
kernels?

Thank you for your time.
Phy

--- Linus Torvalds <torvalds@osdl.org> wrote:
> 
> 
> On Sun, 23 May 2004, Phy Prabab wrote:
> > 
> > I have been researching the 4g patches for
> kernels. 
> > Seems there was a rift between people over this. 
> Is
> > there any plan to resume publishing 4g patches for
> > developing kernels?
> 
> Quite frankly, a number of us are hoping that we can
> make them
> unnecessary. The cost of the 4g/4g split is
> absolutely _huge_ on some
> things, including basic stuff like kernel compiles.
> 
> The only valid reason for the 4g split is that the
> VM doesn't always 
> behave well with huge amounts of highmem. The
> anonvma stuff in 2.6.7-pre1 
> is hoped to make that much less of an issue.
> 
> Personally, if we never need to merge 4g for real,
> I'll be really really 
> happy. I see it as a huge ugly hack.
> 
> 			Linus



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: 4g/4g for 2.6.6

[Martin J. Bligh]

> I have been researching the 4g patches for kernels. 
> Seems there was a rift between people over this.  Is
> there any plan to resume publishing 4g patches for
> developing kernels?
> 
> I am currently trying to get 4g to work with 2.6.6-mm5
> but of course running into issues,so any help on this
> would be great!

It's in -mjb tree - the update from 2.6.6-rc3 to 2.6.6 should be trivial.

M.

Re: 4g/4g for 2.6.6

[Phy Prabab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 718 bytes --]

Okay, I will work with that patch and see if I can it
to apply.

Thanks!
Phy
--- "Martin J. Bligh" <mbligh@aracnet.com> wrote:
> > I have been researching the 4g patches for
> kernels. 
> > Seems there was a rift between people over this. 
> Is
> > there any plan to resume publishing 4g patches for
> > developing kernels?
> > 
> > I am currently trying to get 4g to work with
> 2.6.6-mm5
> > but of course running into issues,so any help on
> this
> > would be great!
> 
> It's in -mjb tree - the update from 2.6.6-rc3 to
> 2.6.6 should be trivial.
> 
> M.
> 


	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: 4g/4g for 2.6.6

[Linus Torvalds]

On Sun, 23 May 2004, Jeff Garzik wrote:
> 
> Sorta like I'm hoping that cheap and prevalent 64-bit CPUs make PAE36 
> and PAE40 on ia32 largely unnecessary.  Addressing more memory than 32 
> bits of memory on a 32-bit CPU always seemed like a hack to me, and a 
> source of bugs and lost performance...

I agree. I held out on PAE for a longish while, in the unrealistic hope 
that people would switch to alpha's. 

Oh, well. I don't expect _everybody_ to switch to x86-64 immediately, but 
I hope we can hold out long enough without 4g that it does work out this 
time.

		Linus

Re: 4g/4g for 2.6.6

[Jeff Garzik]

Linus Torvalds wrote:
> Oh, well. I don't expect _everybody_ to switch to x86-64 immediately, but 
> I hope we can hold out long enough without 4g that it does work out this 
> time.

I think the switchover will happen fairly rapidly, since it is 
positioned "the upgrade you get next time you buy a new computer", 
similar to the current PATA->SATA switchover.

Since these CPUs run in 32-bit mode just fine, I bet you wind up with 
people running Intel or AMD 64-bit CPUs long they abandon their 32-bit 
OS.  I recall people often purchasing gigabit ethernet cards long before 
they had a gigabit switch, simply because it was the volume technology 
that was being at the time.  I think the same thing is going to happen 
here, with AMD64 and EM64T.

AMD got a lot of things right with this one...

	Jeff

Re: 4g/4g for 2.6.6

[Wim Coekaerts]

> I think the switchover will happen fairly rapidly, since it is 
> positioned "the upgrade you get next time you buy a new computer", 
> similar to the current PATA->SATA switchover.

you're thinking what people do at home, the large business side doesn't
throw stuff out.. let me know when rhat replaces every desktop with
amd64, and ll buy you a drink if that's within the next few years ;)

> Since these CPUs run in 32-bit mode just fine, I bet you wind up with 
> people running Intel or AMD 64-bit CPUs long they abandon their 32-bit 
> OS.  I recall people often purchasing gigabit ethernet cards long before 
> they had a gigabit switch, simply because it was the volume technology 
> that was being at the time.  I think the same thing is going to happen 
> here, with AMD64 and EM64T.

yeah well what we can do (and do) is advice that hey 64bit, in some form
is really a much better environment to run servers with lots of gb on.
just takes time for products to mature on the market, even today you
can't get a lot of those boxes, not in bulk, and I am not talking about
a 1 or 2 way or a desktop with 2gb. don't confuse the systems where
4/4gb matters with your home box.

on the plus side, all the changes that went in recently seem to work
mighty well on 32gb, and I still have to see the first 64gb ia32 boxes,
m sure they are out there but I doubt that really matters any more. 

anyhow, the current VM seems to be capable of 32gb systems on ia32
happily without needing ugly 4/4. which is awesome. it's also
interesting  timing. anywys, 2.6 kicks butt quite decently :)

Wim

Re: 4g/4g for 2.6.6

[William Lee Irwin III]

On Sun, May 23, 2004 at 01:32:19PM -0700, Linus Torvalds wrote:
> Quite frankly, a number of us are hoping that we can make them
> unnecessary. The cost of the 4g/4g split is absolutely _huge_ on some
> things, including basic stuff like kernel compiles.
> The only valid reason for the 4g split is that the VM doesn't always 
> behave well with huge amounts of highmem. The anonvma stuff in 2.6.7-pre1 
> is hoped to make that much less of an issue.
> Personally, if we never need to merge 4g for real, I'll be really really 
> happy. I see it as a huge ugly hack.

The performance can be improved by using a u area to store and map
things like vmas, kernel stacks, pagetables, file handles and
descriptor tables, and the like with supervisor privileges in the same
set of pagetables as the user context so that system calls may be
serviced without referencing the larger global kernel data area, which
would require the %cr3 reload. This does, however, seem at odds with
Linux' design in a number of respects, e.g. vmas etc. are on lists
containing elements belonging to different contexts. I suspect kernels
doing this would have to architect their page replacement algorithms
and truncate() semantics so as to avoid these out-of-context accesses
or otherwise suffer these operations being inefficient.

-- wli

Re: 4g/4g for 2.6.6

[Martin J. Bligh]

> Since these CPUs run in 32-bit mode just fine, I bet you wind up with 
> people running Intel or AMD 64-bit CPUs long they abandon their 32-bit OS.  
> I recall people often purchasing gigabit ethernet cards long before they 
> had a gigabit switch, simply because it was the volume technology that 
> was being at the time.  I think the same thing is going to happen here, 
> with AMD64 and EM64T.

Except some bright spark at Intel decided to fix the low end stuff first,
and not the high end stuff for ages. Marvellous - all those 64GB 2 CPU boxes
are fixed. Triples all round. 

> AMD got a lot of things right with this one...

If the rest of the world would catch up, I'd be a happy man ...

M.

Re: 4g/4g for 2.6.6

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Sun, 2004-05-23 at 23:55, Phy Prabab wrote:
> So do I understand this correctly, in 2.6.7(+) it will
> no longer be necessary to have the 4g patches?  I will
> be able to get 4g/process with the going forward
> kernels?

The kernel RPMs I do (http://people.redhat.com/arjanv/2.6/) pretty much
will have it always for 2.6. Not just for large memory configs, but
because several userspace applications (databases, java etc) really like
that extra Gb of virtual space too. 
As for the cost; 4:4 split seems to be hardly expensive at all, only in
some microbenchmarks.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 4g/4g for 2.6.6

[Phy Prabab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 966 bytes --]

Is this source, or precompiled targeting just RH
setups?

Thank you for your help.
Phy

--- Arjan van de Ven <arjanv@redhat.com> wrote:
> On Sun, 2004-05-23 at 23:55, Phy Prabab wrote:
> > So do I understand this correctly, in 2.6.7(+) it
> will
> > no longer be necessary to have the 4g patches?  I
> will
> > be able to get 4g/process with the going forward
> > kernels?
> 
> The kernel RPMs I do
> (http://people.redhat.com/arjanv/2.6/) pretty much
> will have it always for 2.6. Not just for large
> memory configs, but
> because several userspace applications (databases,
> java etc) really like
> that extra Gb of virtual space too. 
> As for the cost; 4:4 split seems to be hardly
> expensive at all, only in
> some microbenchmarks.
> 

> ATTACHMENT part 2 application/pgp-signature
name=signature.asc



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: 4g/4g for 2.6.6

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

On Mon, May 24, 2004 at 12:11:26AM -0700, Phy Prabab wrote:
> Is this source, or precompiled targeting just RH
> setups?

it's both actually.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 4g/4g for 2.6.6

[Phy Prabab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 539 bytes --]

Thats great!  Do you include a change file to see what
other patches have been applied?

Thank you very much for your help.
Phy

--- Arjan van de Ven <arjanv@redhat.com> wrote:
> On Mon, May 24, 2004 at 12:11:26AM -0700, Phy Prabab
> wrote:
> > Is this source, or precompiled targeting just RH
> > setups?
> 
> it's both actually.
> 

> ATTACHMENT part 2 application/pgp-signature 



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: 4g/4g for 2.6.6

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> Quite frankly, a number of us are hoping that we can make them
> unnecessary. The cost of the 4g/4g split is absolutely _huge_ on some
> things, including basic stuff like kernel compiles.
>
> The only valid reason for the 4g split is that the VM doesn't always
> behave well with huge amounts of highmem. The anonvma stuff in
> 2.6.7-pre1 is hoped to make that much less of an issue.
>
> Personally, if we never need to merge 4g for real, I'll be really
> really happy. I see it as a huge ugly hack.

i agree with the hack part - but the performance aspect has been blown
out of proportion. 4:4 has the same cost on kernel compiles as highpte.
There are also real workloads where it actually helps performance.

also, the 4:4 overhead is really a hardware problem - and there are
x86-compatible CPUs (amd64) where the TLB flush problem has already been
solved: on amd64 the 4:4 feature has no noticeable overhead. So as long
as people opt for a 32-bit OS (even on a 64-bit CPU, for whatever weird
compatibility reason), 4:4 can be useful. For the other workloads i as
much hope as everyone else that people switch to a 64-bit OS on x86-64
ASAP!

also, while a quick transition to x86-64 will most likely happen, the
large installed base of big x86 boxes is a matter of fact too - and they
wont vanish into thin air. Also, there will always be specific user
workloads where lowmem grows to large values. Not to mention the fact
that 4:4 is a nice debugging/security tool as you cannot dereference
user pointers ;) - it has caught countless bugs already. Plus there are
specific workloads that want 4GB of userspace (and no, 3.5 GB wont do).

So 4:4 will have its niches where it will live on. We could argue on and
on how quickly 'x86 with more than 4GB of RAM' and 'x86 with 4GB of a
userspace' will become a niche, hopefully it happens fast but we've got
to keep our options open.

	Ingo

Re: 4g/4g for 2.6.6

[Thomas Glanzmann]

Hi,

> a coworker made the old 4g patch ready to apply clean into 2.6.6 . He's
> also working on a nice model, I think he's reading lkml so maybe he'll
> answer.

forget the URL:

http://wwwcip.informatik.uni-erlangen.de/~sithglan/2.6.6-4g

	Thomas

Re: 4g/4g for 2.6.6

[Dave Jones]

On Mon, May 24, 2004 at 12:27:05AM -0700, Phy Prabab wrote:
 > Thats great!  Do you include a change file to see what
 > other patches have been applied?

It's in the kernel-2.6.spec in those RPMs.

		Dave

Re: 4g/4g for 2.6.6

[Andrea Arcangeli]

On Mon, May 24, 2004 at 10:25:22AM +0200, Ingo Molnar wrote:
> on how quickly 'x86 with more than 4GB of RAM' and 

s/4GB/32GB/

my usual x86 test box has 48G of ram (though to keep an huge margin of
safety we assume 32G is the very safe limit).

Re: 4g/4g for 2.6.6

[Rik van Riel]

On Mon, 24 May 2004, Andrea Arcangeli wrote:
> On Mon, May 24, 2004 at 10:25:22AM +0200, Ingo Molnar wrote:
> > on how quickly 'x86 with more than 4GB of RAM' and 
> 
> s/4GB/32GB/
> 
> my usual x86 test box has 48G of ram (though to keep an huge margin of
> safety we assume 32G is the very safe limit).

Just how many 3GB sized processes can you run on that
system, if each of them have a hundred or so VMAs ?

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: 4g/4g for 2.6.6

[Andrea Arcangeli]

On Tue, May 25, 2004 at 03:15:14PM -0400, Rik van Riel wrote:
> On Mon, 24 May 2004, Andrea Arcangeli wrote:
> > On Mon, May 24, 2004 at 10:25:22AM +0200, Ingo Molnar wrote:
> > > on how quickly 'x86 with more than 4GB of RAM' and 
> > 
> > s/4GB/32GB/
> > 
> > my usual x86 test box has 48G of ram (though to keep an huge margin of
> > safety we assume 32G is the very safe limit).
> 
> Just how many 3GB sized processes can you run on that
> system, if each of them have a hundred or so VMAs ?

with 400m of normal zone we can allocate 5000000 vmas, if each task uses
100 of them that's around 50000 processes. The 3G size doesn't matter.

I think you meant each task using some _dozen_thousand_ of vmas (not
hundreds), that's what actually happens with 32k large vmas spread over
2G of shared memory on some database (assuming no merging, with merging
it goes down to the few thousands), but remap_file_pages has been
designed exactly to avoid allocating several thousands of VMA per task,
no? So it's just 1 vma per task (plus a few more vmas for the binary
shared libs and anonymous memory).

Clearly by opening enough files or enough network sockets or enough vmas
or similar, you can still run out of normal zone, even on a 2G system,
but this is not the point or you would be shipping 4:4 on the 2G systems
too, no? We're not trying to make it impossible to run out of zone
normal, even 4:4 can't make that impossible to happen on >4G boxes.

Re: 4g/4g for 2.6.6

[Manfred Spraul]

Ingo wrote:

>also, the 4:4 overhead is really a hardware problem - and there are
>x86-compatible CPUs (amd64) where the TLB flush problem has already been
>solved: on amd64 the 4:4 feature has no noticeable overhead.
>
Do you have an idea why amd64 is better for 4g4g? Which benchmark did 
you use for testing?

--
    Manfred

Re: 4g/4g for 2.6.6

[Rik van Riel]

On Tue, 25 May 2004, Andrea Arcangeli wrote:

> Clearly by opening enough files or enough network sockets or enough vmas
> or similar, you can still run out of normal zone, even on a 2G system,
> but this is not the point or you would be shipping 4:4 on the 2G systems
> too, no?

The point is, people like to run bigger workloads on
bigger systems. Otherwise they wouldn't bother buying
those bigger systems.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: 4g/4g for 2.6.6

[Ingo Molnar]

* Manfred Spraul <manfred@colorfullife.com> wrote:

> >also, the 4:4 overhead is really a hardware problem - and there are
> >x86-compatible CPUs (amd64) where the TLB flush problem has already been
> >solved: on amd64 the 4:4 feature has no noticeable overhead.
> >
> Do you have an idea why amd64 is better for 4g4g? Which benchmark did
> you use for testing?

i used an althlon64 CPU. amd64 is better because it has a hardware
feature that 'watches' for memory updates to cached TLBs, and it tags
the TLBs by cr3. So it can avoid having to flush those TLBs that didnt
actually change. So an amd64 CPU has in excess of 1000+ TLBs ...

	Ingo

Re: 4g/4g for 2.6.6

[Rik van Riel]

On Tue, 25 May 2004, Rik van Riel wrote:

> The point is, people like to run bigger workloads on
> bigger systems. Otherwise they wouldn't bother buying
> those bigger systems.

Btw, you're right about the VMAs.  Looking through customer
stuff a bit more the more common issues are low memory being
eaten by dentry / inode cache - which you can't always reclaim
due to files being open, and don't always _want_ to reclaim
because that could well be a bigger performance hit than the
4:4 split.

The primary impact of the dentry / inode cache using memory
isn't lowmem exhaustion, btw.  It's lowmem fragmentation.

Fragmentation causes fork trouble (gone with the 4k stacks)
and trouble for the network layer and kiobuf allocation,
which still do need higher order allocations.

Sure, the 4/4 kernel could also have problems with lowmem
fragmentation, but it just seems to be nowhere near as bad.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: 4g/4g for 2.6.6

[Bill Davidsen]

Rik van Riel wrote:
> On Tue, 25 May 2004, Andrea Arcangeli wrote:
> 
> 
>>Clearly by opening enough files or enough network sockets or enough vmas
>>or similar, you can still run out of normal zone, even on a 2G system,
>>but this is not the point or you would be shipping 4:4 on the 2G systems
>>too, no?
> 
> 
> The point is, people like to run bigger workloads on
> bigger systems. Otherwise they wouldn't bother buying
> those bigger systems.
> 

Sure, and "bigger workloads" can mean a lot of small client processes 
talking to a threaded large process, like database or news, or it can be 
huge datasets, like image or multimedia processing. Unfortunately it 
seems that these all (ab)use the VM in various ways.

x86 with lots of memory is likely to remain cost effective for years, 
not only because it not only allows more memory but needs more memory in 
most cases, but because vendors will hang on to their profit margins on 
64 bit CPUs for that long. And for uses with many small client 
processes, the advantage of 64 bits is pretty small when you have 2MB 
processes. Given a bus which allows i/o to more memory, the benefits in 
performance are really hard to see.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 4g/4g for 2.6.6

[Andrea Arcangeli]

On Tue, May 25, 2004 at 04:10:29PM -0400, Rik van Riel wrote:
> Fragmentation causes fork trouble (gone with the 4k stacks)

btw, the 4k stacks sounds not safe to me, most people only tested with
8k stacks so far, I wouldn't make that change in a production tree
without an unstable cycle of testing in between. I'd rather risk a
an allocation failure than a stack memory corruption.

x86-64 has per-irq stacks that allowed to reduce the stack size to 8k
(which is very similar to 4k for an x86, but without per-irq stack it's
too risky).

as for the dcache size, I can certainly imagine you can measure slowdown
bigger than 4:4 in some very vfs intensive workload, but the stuff that
needs 32G of ram normally uses only rawio or a few huge files as storage
anyways. as for the kiobufs they're long gone in 2.6.

Possibly some webserving could use 32G as pure pagecache for the
webserver with tons of tiny files, for such an app the 2:2 or 1:3 model
should be better than 4:4.

Re: 4g/4g for 2.6.6

[Andrew Morton]

Rik van Riel <riel@redhat.com> wrote:
>
> On Tue, 25 May 2004, Rik van Riel wrote:
> 
> > The point is, people like to run bigger workloads on
> > bigger systems. Otherwise they wouldn't bother buying
> > those bigger systems.
> 
> Btw, you're right about the VMAs.  Looking through customer
> stuff a bit more the more common issues are low memory being
> eaten by dentry / inode cache - which you can't always reclaim
> due to files being open, and don't always _want_ to reclaim
> because that could well be a bigger performance hit than the
> 4:4 split.

I did some testing a year or two back with the normal zone wound down to a
few hundred megs - filesytem benchmarks were *severely* impacted by the
increased turnover rate of fs metadata pagecache and VFS caches.  I forget
the details, but it was "wow".

> The primary impact of the dentry / inode cache using memory
> isn't lowmem exhaustion, btw.  It's lowmem fragmentation.
> 
> Fragmentation causes fork trouble (gone with the 4k stacks)
> and trouble for the network layer and kiobuf allocation,
> which still do need higher order allocations.

I'm suspecting we'll end up needing mempools (or something) of 1- and
2-order pages to support large-frame networking.  I'm surprised there isn't
more pressure to do something about this.  Maybe people are increasing
min_free_kbytes.

Re: 4g/4g for 2.6.6

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > Btw, you're right about the VMAs.  Looking through customer
> > stuff a bit more the more common issues are low memory being
> > eaten by dentry / inode cache - which you can't always reclaim
> > due to files being open, and don't always _want_ to reclaim
> > because that could well be a bigger performance hit than the
> > 4:4 split.
> 
> I did some testing a year or two back with the normal zone wound down
> to a few hundred megs - filesytem benchmarks were *severely* impacted
> by the increased turnover rate of fs metadata pagecache and VFS
> caches.  I forget the details, but it was "wow".

and it's not only the normal workloads we know about - people really do
lots of weird stuff with Linux (and we are happy that they use Linux and
that Linux keeps chugging along), and people seem to prefer a 10%
slowdown to a box that locks up or -ENOMEM's. I'm not trying to insert
any unjustified fear, 3:1 can be ok with lots of RAM, but it's _clearly_
wishful thinking that 32 GB x86 will be OK with just 600 MB of lowmem.
600 MB of lowmem means a 1:80 lowmem to RAM ratio, which is insane. Yes,
it will be OK with select workloads and applications. With 4:4 it's 3.4
GB lowmem and the ratio is down to a much saner 1:9, and boxes pushed
against the wall keep up better.

(but i wont attempt to convince Andrea - and i'm not at all unhappy that
he is trying to fix 3:1 to be more usable on big boxes because those
efforts also decrease the RAM footprint of the UP kernel, which is
another sensitive area. These efforts also help sane 64-bit
architectures, so it's a win-win situation even considering our
disagreement wrt. 4:4.)

> I'm suspecting we'll end up needing mempools (or something) of 1- and
> 2-order pages to support large-frame networking.  I'm surprised there
> isn't more pressure to do something about this.  Maybe people are
> increasing min_free_kbytes.

hm, 1.5K pretty much seems to be the standard. Plus large frames can be
scatter-gathered via fragmented skbs. Seldom is there a need for a large
skb to be linear.

	Ingo

Re: 4g/4g for 2.6.6

[David S. Miller]

On Tue, 25 May 2004 23:48:17 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> hm, 1.5K pretty much seems to be the standard. Plus large frames can be
> scatter-gathered via fragmented skbs. Seldom is there a need for a large
> skb to be linear.

Unfortunately TSO with non-sendfile apps makes huge 64K SKBs get
built.

Re: 4g/4g for 2.6.6

[Ingo Molnar]

* David S. Miller <davem@redhat.com> wrote:

> > hm, 1.5K pretty much seems to be the standard. Plus large frames can be
> > scatter-gathered via fragmented skbs. Seldom is there a need for a large
> > skb to be linear.
> 
> Unfortunately TSO with non-sendfile apps makes huge 64K SKBs get
> built.

hm, shouldnt we disable TSO in this case - or is it a win even in this
case?

	Ingo

Re: 4g/4g for 2.6.6

[David S. Miller]

On Wed, 26 May 2004 00:20:32 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> > Unfortunately TSO with non-sendfile apps makes huge 64K SKBs get
> > built.
> 
> hm, shouldnt we disable TSO in this case - or is it a win even in this
> case?

It is a win even in this case.

4k stacks in 2.6

[Ingo Molnar]

* Andrea Arcangeli <andrea@suse.de> wrote:

> On Tue, May 25, 2004 at 04:10:29PM -0400, Rik van Riel wrote:
> > Fragmentation causes fork trouble (gone with the 4k stacks)
> 
> btw, the 4k stacks sounds not safe to me, most people only tested with
> 8k stacks so far, I wouldn't make that change in a production tree
> without an unstable cycle of testing in between. I'd rather risk a an
> allocation failure than a stack memory corruption.

4k stacks is a cool and useful feature and tons of effort that went into
making them as safe as possible. Sure, we couldnt fix up bin-only
modules, but all the kernel drivers are audited for stack footprint, and
many months of beta testing has gone into this as well. Anyway, if you
prefer you can turn on 8k stacks - especially if you tree has lots of
not-yet-upstream driver patches.

> x86-64 has per-irq stacks that allowed to reduce the stack size to 8k
> (which is very similar to 4k for an x86, but without per-irq stack
> it's too risky).

do you realize that the 4K stacks feature also adds a separate softirq
and a separate hardirq stack? So the maximum footprint is 4K+4K+4K, with
a clear and sane limit for each type of context, while the 2.4 kernel
has 6.5K for all 3 contexts combined. (Also, in 2.4 irq contexts pretty
much assumed that there's 2K of stack for them - leaving a de-facto 4K
stack for the process and softirq contexts.) So in fact there is more
space in 2.6 for all, and i dont really understand your fears.

	Ingo

Re: 4k stacks in 2.6

[Jörn Engel]

On Wed, 26 May 2004 12:33:03 +0200, Ingo Molnar wrote:
> * Andrea Arcangeli <andrea@suse.de> wrote:
> > On Tue, May 25, 2004 at 04:10:29PM -0400, Rik van Riel wrote:
> > > Fragmentation causes fork trouble (gone with the 4k stacks)
> > 
> > btw, the 4k stacks sounds not safe to me, most people only tested with
> > 8k stacks so far, I wouldn't make that change in a production tree
> > without an unstable cycle of testing in between. I'd rather risk a an
> > allocation failure than a stack memory corruption.
> 
> 4k stacks is a cool and useful feature and tons of effort that went into
> making them as safe as possible. Sure, we couldnt fix up bin-only
> modules, but all the kernel drivers are audited for stack footprint, and
> many months of beta testing has gone into this as well. Anyway, if you
> prefer you can turn on 8k stacks - especially if you tree has lots of
> not-yet-upstream driver patches.
> 
> > x86-64 has per-irq stacks that allowed to reduce the stack size to 8k
> > (which is very similar to 4k for an x86, but without per-irq stack
> > it's too risky).
> 
> do you realize that the 4K stacks feature also adds a separate softirq
> and a separate hardirq stack? So the maximum footprint is 4K+4K+4K, with
> a clear and sane limit for each type of context, while the 2.4 kernel
> has 6.5K for all 3 contexts combined. (Also, in 2.4 irq contexts pretty
> much assumed that there's 2K of stack for them - leaving a de-facto 4K
> stack for the process and softirq contexts.) So in fact there is more
> space in 2.6 for all, and i dont really understand your fears.

Experience indicates that for whatever reason, big stack consumers for
all three contexts never hit at the same time.  Big stack consumers
for one context happen too often, though.  "Too often" may be quite
rare, but considering the result of a stack overflow, even "quite
rare" is too much.  "Never" is the only acceptable target.

Change gcc to catch stack overflows before the fact and disallow
module load unless modules have those checks as well.  If that is
done, a stack overflow will merely cause a kernel panic.  Until then,
I am just as conservative as Andreas.

Jörn

-- 
And spam is a useful source of entropy for /dev/random too!
-- Jasmine Strong

Re: 4k stacks in 2.6

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Wed, May 26, 2004 at 02:50:14PM +0200, Jörn Engel wrote:
> 
> Experience indicates that for whatever reason, big stack consumers for
> all three contexts never hit at the same time.  Big stack consumers
> for one context happen too often, though.  "Too often" may be quite
> rare, but considering the result of a stack overflow, even "quite
> rare" is too much.  "Never" is the only acceptable target.

Actually it's not mever in 2.4. It does get here there by our customers once
in a while. Esp with several NICs hitting an irq on the same CPU (eg the irq
context goes over it's 2Kb limit)

> done, a stack overflow will merely cause a kernel panic.  Until then,
> I am just as conservative as Andreas.

actually the 4k stacks approach gives MORE breathing room for the problem
cases that are getting hit by our customers...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 4k stacks in 2.6

[Jörn Engel]

On Wed, 26 May 2004 14:53:00 +0200, Arjan van de Ven wrote:
> On Wed, May 26, 2004 at 02:50:14PM +0200, Jörn Engel wrote:
> > 
> > Experience indicates that for whatever reason, big stack consumers for
> > all three contexts never hit at the same time.  Big stack consumers
> > for one context happen too often, though.  "Too often" may be quite
> > rare, but considering the result of a stack overflow, even "quite
> > rare" is too much.  "Never" is the only acceptable target.
> 
> Actually it's not mever in 2.4. It does get here there by our customers once
> in a while. Esp with several NICs hitting an irq on the same CPU (eg the irq
> context goes over it's 2Kb limit)
> 
> > done, a stack overflow will merely cause a kernel panic.  Until then,
> > I am just as conservative as Andreas.
> 
> actually the 4k stacks approach gives MORE breathing room for the problem
> cases that are getting hit by our customers...

For the cases you described, yes.  For some others like nvidia, no.
Not sure if we want to make things worse for some users in order to
improve things for others (better paying ones?).  I want the seperate
interrupt stacks, sure.  I'm just not comfy with 4k per process yet.

But I'll shut up now and see if I can generate better data over the
weekend.  -test11 still had fun stuff like 3k stack consumption over
some code paths in a pretty minimal kernel.  Wonder what 2.6.6 will do
with allyesconfig. ;)

Jörn

-- 
He who knows that enough is enough will always have enough.
-- Lao Tsu

Re: 4k stacks in 2.6

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Wed, May 26, 2004 at 03:00:47PM +0200, Jörn Engel wrote:
> > > Experience indicates that for whatever reason, big stack consumers for
> > > all three contexts never hit at the same time.  Big stack consumers
> > > for one context happen too often, though.  "Too often" may be quite
> > > rare, but considering the result of a stack overflow, even "quite
> > > rare" is too much.  "Never" is the only acceptable target.
> > 

> > actually the 4k stacks approach gives MORE breathing room for the problem
> > cases that are getting hit by our customers...
> 
> For the cases you described, yes.  For some others like nvidia, no.
> Not sure if we want to make things worse for some users in order to
> improve things for others (better paying ones?).  I want the seperate


You used the word "Never" and now you go away from it.... It wasn't Never,
and it will never be never if you want to include random binary only
modules. However in 2.4 for all intents and pruposes there was 4Kb already,
and now there still is, for user context. Because those interrupts DO
happen. NVidia was a walking timebomb, and with one function using 4Kb
that's an obvious Needs-Fix case. The kernel had a few of those in rare
drivers, most of which have been fixed by now. It'll never be never, but it
never was never either.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 4k stacks in 2.6

[Jörn Engel]

On Wed, 26 May 2004 15:05:00 +0200, Arjan van de Ven wrote:
> 
> You used the word "Never" and now you go away from it.... It wasn't Never,
> and it will never be never if you want to include random binary only
> modules. However in 2.4 for all intents and pruposes there was 4Kb already,
> and now there still is, for user context. Because those interrupts DO
> happen. NVidia was a walking timebomb, and with one function using 4Kb
> that's an obvious Needs-Fix case. The kernel had a few of those in rare
> drivers, most of which have been fixed by now. It'll never be never, but it
> never was never either.

In a way, you are right.  nVidia was and is a walking timebomb and
making bugs more likely to happen is a good thing in general.  Except
that this bug can eat filesystems, so making it more likely will cause
more filesystems to be eaten.

Anyway, whether we go for 4k in 2.6 or not, we should do our best to
fix bad code and I will go looking for some more so others can go and
fix some more.  There's still enough horror in mainline for more than
one amusement park, we just haven't found it yet.

Jörn

-- 
All art is but imitation of nature.
-- Lucius Annaeus Seneca

Re: 4k stacks in 2.6

[David S. Miller]

On Wed, 26 May 2004 14:50:14 +0200
Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:

> Change gcc to catch stack overflows before the fact and disallow
> module load unless modules have those checks as well.

That's easy, just enable profiling then implement a suitable
_mcount that checks for stack overflow.  I bet someone has done
this already.

For full coverage, some trap entry handler checks in entry.S
would be necessary too of course.

Re: 4k stacks in 2.6

[Matt Mackall]

On Wed, May 26, 2004 at 11:12:22AM -0700, David S. Miller wrote:
> On Wed, 26 May 2004 14:50:14 +0200
> J?rn Engel <joern@wohnheim.fh-wedel.de> wrote:
> 
> > Change gcc to catch stack overflows before the fact and disallow
> > module load unless modules have those checks as well.
> 
> That's easy, just enable profiling then implement a suitable
> _mcount that checks for stack overflow.  I bet someone has done
> this already.

There was a patch floating around for this in the 2.2 era that I
ported to 2.4 on one occassion. It won't tell you worst case though,
just worst observed case.

Sparse is probably not a bad place to put a real call chain stack analysis.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 4k stacks in 2.6

[Dave Jones]

On Wed, May 26, 2004 at 02:02:22PM -0500, Matt Mackall wrote:

 > There was a patch floating around for this in the 2.2 era that I
 > ported to 2.4 on one occassion. It won't tell you worst case though,
 > just worst observed case.
 > 
 > Sparse is probably not a bad place to put a real call chain stack analysis.

That won't measure any dynamic stack allocations that we're doing
at runtime, nor will it test all n combinations of drivers, which
is where most of the stack horrors have been found in recent times.

		Dave

Re: 4k stacks in 2.6

[Ingo Molnar]

* Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:

> Anyway, whether we go for 4k in 2.6 or not, [...]

4K stacks have been added to the 2.6 kernel more than a month ago, are
in the official 2.6.6 kernel and are used by FC2 happily, so objections
are a bit belated. I only reacted to Andrea's mail to clear up apparent
misunderstandings about the impact and implementation of this feature.

	Ingo

Re: 4k stacks in 2.6

[Andrea Arcangeli]

On Thu, May 27, 2004 at 02:45:51PM +0200, Ingo Molnar wrote:
> are a bit belated. I only reacted to Andrea's mail to clear up apparent
> misunderstandings about the impact and implementation of this feature.

note that there is something relevant to improve in the implementation,
that is the per-cpu irq stack size should be bigger than 4k, we use 16k
on x86-64, on x86 it should be 8k. Currently you're decreasing _both_
the normal kernel context and even the irq stack in some condition.
There's no good reason to decrease the irq stack too, that's cheap, it's
per-cpu.

Re: 4k stacks in 2.6

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]


On Thu, May 27, 2004 at 03:59:30PM +0200, Andrea Arcangeli wrote:
> On Thu, May 27, 2004 at 02:45:51PM +0200, Ingo Molnar wrote:
> > are a bit belated. I only reacted to Andrea's mail to clear up apparent
> > misunderstandings about the impact and implementation of this feature.
> 
> note that there is something relevant to improve in the implementation,
> that is the per-cpu irq stack size should be bigger than 4k, we use 16k
> on x86-64, on x86 it should be 8k. Currently you're decreasing _both_
> the normal kernel context and even the irq stack in some condition.
> There's no good reason to decrease the irq stack too, that's cheap, it's
> per-cpu.

In theory you are absolutely right, problem is the current macro..... it's
SO much easier to have one stacksize everywhere (and cheaper too) for
this... (and it hasn't been a problem so far, esp since the softirq's have
their own stack, irq handlers seem to be all really light on the stack
already since they punt all the heavy lifting to tasklets etc.
Tasklets don't recurse stack wise, and have their own stack, so that ought
to be fine.

On x86_64 you have the PDA for current so that's not a problem, and you can
do the bigger stacks easily but for x86 you don't...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 4k stacks in 2.6

[Brian Gerst]

Andrea Arcangeli wrote:

> On Thu, May 27, 2004 at 02:45:51PM +0200, Ingo Molnar wrote:
> 
>>are a bit belated. I only reacted to Andrea's mail to clear up apparent
>>misunderstandings about the impact and implementation of this feature.
> 
> 
> note that there is something relevant to improve in the implementation,
> that is the per-cpu irq stack size should be bigger than 4k, we use 16k
> on x86-64, on x86 it should be 8k. Currently you're decreasing _both_
> the normal kernel context and even the irq stack in some condition.
> There's no good reason to decrease the irq stack too, that's cheap, it's
> per-cpu.

The problem on i386 (unlike x86-64) is that the thread_info struct sits 
at the bottom of the stack and is referenced by masking bits off %esp. 
So the stack size must be constant whether in process context or IRQ 
context.

--
				Brian Gerst

Re: 4k stacks in 2.6

[Andrea Arcangeli]

On Thu, May 27, 2004 at 04:03:22PM +0200, Arjan van de Ven wrote:
> In theory you are absolutely right, problem is the current macro..... it's
> SO much easier to have one stacksize everywhere (and cheaper too) for
> this... (and it hasn't been a problem so far, esp since the softirq's have

I see the problem, but then why don't we wait to implement it right, to
allow 8k irq-stacks before merging into mainline?

grep for "~s 4k" (i.e. the word "4[kK]" in the subject) on l-k and
you'll see there's more than just nvidia. one user reported not being
able to boot at all with 4k stacks since 2.6.6 doesn't have a stack
overflow in the oops, so I hope he tested w/ and w/o 4KSTACKS option
enabled to be able to claim what broke his machine is the 4KSTACKS
option. (his oops doesn't reveal a stack overflow, the thread_info is at
0xf000 and the esp is at 0xffxx)

Making it a config option, is a sort of proof that you agree it can
break something, or you wouldn't make it a config option in the first
place. What's the point of making it a configuration option if it cannot
break anything and if it's not risky? Making it a config option is not
good, because then some developer may develop leaving 4KSTACKS disabled,
and then his kernel code might break on the users with 4KSTACKS enabled
(it's not much different from PREEMPT).  Amittedly code that overflows
4k is likely to be not legitimate but not all code is good (the most
common error is to allocate big strutures locally on the stack with
local vars), and if developers are able to notice the overflow on their
own testing it's better.

Clearly it's more relaxed to merge something knowing with a config
option you can choose if to use 4k or 8k stacks, but I'm not sure if
it's the right thing to do for the long term. If we go 4k stacks, then
I'd prefer that you drop the 4KSTACKS option and force people to reduce
the stack usage in their code, and secondly that we fixup the irqstack
to be 8k.

Plus the allocation errors you had, could be just 2.6 vm issues with
order > 0 allocations, we never had issues with 8k stacks in 2.4, so
using the 4k stacks may just hide the real problem. archs like x86-64
have to use order > 0 allocations for kernel stack, no way around it, so
order > 0 must work reliably regardless of whatever code we change in
x86.

> On x86_64 you have the PDA for current so that's not a problem, and
> you can do the bigger stacks easily but for x86 you don't...

yep.

Re: 4k stacks in 2.6

[Andrea Arcangeli]

On Thu, May 27, 2004 at 10:18:40AM -0400, Brian Gerst wrote:
> The problem on i386 (unlike x86-64) is that the thread_info struct sits 
> at the bottom of the stack and is referenced by masking bits off %esp. 
> So the stack size must be constant whether in process context or IRQ 
> context.

so what, that's a minor implementation detail, pda is a software thing.

Re: 4k stacks in 2.6

[Linus Torvalds]

On Thu, 27 May 2004, Andrea Arcangeli wrote:
>
> On Thu, May 27, 2004 at 10:18:40AM -0400, Brian Gerst wrote:
> > The problem on i386 (unlike x86-64) is that the thread_info struct sits 
> > at the bottom of the stack and is referenced by masking bits off %esp. 
> > So the stack size must be constant whether in process context or IRQ 
> > context.
> 
> so what, that's a minor implementation detail, pda is a software thing.

"minor implementation detail"?

You need to get to the thread info _some_ way, and you need to get to it
_fast_. There are really no sane alternatives. I certainly do not want to
play games with segments.

		Linus

Re: 4k stacks in 2.6

[Andrea Arcangeli]

On Thu, May 27, 2004 at 07:55:36AM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 27 May 2004, Andrea Arcangeli wrote:
> >
> > On Thu, May 27, 2004 at 10:18:40AM -0400, Brian Gerst wrote:
> > > The problem on i386 (unlike x86-64) is that the thread_info struct sits 
> > > at the bottom of the stack and is referenced by masking bits off %esp. 
> > > So the stack size must be constant whether in process context or IRQ 
> > > context.
> > 
> > so what, that's a minor implementation detail, pda is a software thing.
> 
> "minor implementation detail"?
> 
> You need to get to the thread info _some_ way, and you need to get to it
> _fast_. There are really no sane alternatives. I certainly do not want to
> play games with segments.

If the page is "even" the thread_info is at the top of the stack. If the
page is "odd" the thread_info is at the bottom of the stack (or the
other way around depending what you mean with "odd" and "even").

the per-cpu irq stack will have the thread_info at both the top and the
bottom of the 8k naturally aligned order1 compound page. The regular
kernel stack will have it at the top or the bottom depending if it's odd
or even.

this should allow 8k irqstack and bh stack fine at in-cpu-core speed w/o
segments or similar.

The only downside is that itadds a branch to current_thread_info that
will have to check the 12th bitflag in the esp before doing andl, the
second downside is having to update two thread_info during irq, instead
of just one.

It would be probably better if the thread_info was just a pointer to a
"pda" instead of being the PDA itself so there are just two writes into
the kernel stack for every irq. In x86-64 this is much more natural
since the pda-pointer is in the cpu 64bit %gs register and that saves a
branch and defereference on the stack for every "current" invocation,
and two writes for every first-irq or first-bh. 

Re: 4k stacks in 2.6

[Guy Sotomayor]

On Thu, 2004-05-27 at 07:55, Linus Torvalds wrote:

> "minor implementation detail"?
> 
> You need to get to the thread info _some_ way, and you need to get to it
> _fast_. There are really no sane alternatives. I certainly do not want to
> play games with segments.

While segments on x86 are in general to be avoided (aka the 286
segmented memory models) they can be useful for some things in the
kernel.

Here's a couple of examples:
      * dereference gs:0 to get the thread info.  The first element in
        the structure is its linear address (ie usable for being deref'd
        off of DS).
      * use SS to enforce the stack limit.  This way you'd absolutely
        get an exception when there was a stack overflow (underflow). 
        SS gets reloaded on entry into the kernel and on interrupts
        anyway so there really shouldn't be a performance impact.  I
        haven't looked at all the (potential) gcc implications here so
        this one may not be completely doable.
-- 

TTFN - Guy

Re: 4k stacks in 2.6

[Brian Gerst]

Guy Sotomayor wrote:

> On Thu, 2004-05-27 at 07:55, Linus Torvalds wrote:
> 
> 
>>"minor implementation detail"?
>>
>>You need to get to the thread info _some_ way, and you need to get to it
>>_fast_. There are really no sane alternatives. I certainly do not want to
>>play games with segments.
> 
> 
> While segments on x86 are in general to be avoided (aka the 286
> segmented memory models) they can be useful for some things in the
> kernel.
> 
> Here's a couple of examples:
>       * dereference gs:0 to get the thread info.  The first element in
>         the structure is its linear address (ie usable for being deref'd
>         off of DS).

The only problem with using %gs as a base register is that reloading it 
on every entry and exit is rather expensive (GDT access and priviledge 
checks) compared to masking bits off %esp.  x86-64 can get away with it 
because it has the swapgs instruction which makes it efficient to use.

>       * use SS to enforce the stack limit.  This way you'd absolutely
>         get an exception when there was a stack overflow (underflow). 
>         SS gets reloaded on entry into the kernel and on interrupts
>         anyway so there really shouldn't be a performance impact.  I
>         haven't looked at all the (potential) gcc implications here so
>         this one may not be completely doable.

Not possible.  GCC completely assumes that we are working with a single 
flat address space.  It has no concept of segmentation at all.

--
				Brian Gerst

Re: 4g/4g for 2.6.6

[Pavel Machek]

Hi!

> > I think the switchover will happen fairly rapidly, since it is 
> > positioned "the upgrade you get next time you buy a new computer", 
> > similar to the current PATA->SATA switchover.
> 
> you're thinking what people do at home, the large business side doesn't
> throw stuff out.. let me know when rhat replaces every desktop with
> amd64, and ll buy you a drink if that's within the next few years ;)
> 

Desktops do not tent to have 4GB+ memory.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: 4g/4g for 2.6.6

[Eric W. Biederman]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 23 May 2004, Jeff Garzik wrote:
> > 
> > Sorta like I'm hoping that cheap and prevalent 64-bit CPUs make PAE36 
> > and PAE40 on ia32 largely unnecessary.  Addressing more memory than 32 
> > bits of memory on a 32-bit CPU always seemed like a hack to me, and a 
> > source of bugs and lost performance...
> 
> I agree. I held out on PAE for a longish while, in the unrealistic hope 
> that people would switch to alpha's. 
> 
> Oh, well. I don't expect _everybody_ to switch to x86-64 immediately, but 
> I hope we can hold out long enough without 4g that it does work out this 
> time.

Sounds sane. 

One of the real problems on machines with more than 4GB in 32bit mode
is where do you put all of the pci resources.  Especially when you start
getting into machines with large memory mapped resources of 128MB or more.

On Intel chipsets that is usually not a problem because you can relocate the
memory from under those resources and still get at it with PAE36.  Other
chipsets don't really have that kind of capability.

>From what I can tell all of the large PCI memory mapped resources are
64bit.  Which gives another solution of simply moving all of those
large memory mapped I/O resources above the memory entirely.  Besides
solving my immediate problem of loosing 1/2GB of memory in some
cases, that looks like the only sane long term solution.

So to encourage x86-64 usage, I am going to implement that in
LinuxBIOS and encourage any other BIOS vendor I run into to
follow suit.  That way the only painful customer questions I will
get will be why doesn't this high performance card work with a
32bit kernel :)  Which is much easier to explain :)

Can anyone think of a reason that would not be a good solution?


Eric

Re: 4k stacks in 2.6 [worst offenders]

[Jörn Engel]

[-- Attachment #1: Type: text/plain, Size: 14303 bytes --]

On Wed, 26 May 2004 18:41:29 +0200, Jörn Engel wrote:
> 
> Anyway, whether we go for 4k in 2.6 or not, we should do our best to
> fix bad code and I will go looking for some more so others can go and
> fix some more.  There's still enough horror in mainline for more than
> one amusement park, we just haven't found it yet.

Here's some.  My tool is still buggy, so if any results don't make
sense, please tell me.  Full results are a bit verbose (2M), but
compress quite well, so I have them attached.  For the lazy, here are
a few interesting things.  First the recursions that shouldn't iterate
too often:

WARNING: recursion detected:
       0  default_wake_function
      36  try_to_wake_up
       0  task_rq_unlock
       0  preempt_schedule
      68  schedule
      52  load_balance
       0  find_busiest_queue
       0  double_lock_balance
       0  __preempt_spin_lock
       0  _raw_spin_lock
       0  printk
       0  printk
      16  release_console_sem
      16  __wake_up
       0  __wait_queue->func
WARNING: recursion detected:
      12  kfree
      12  cache_flusharray
      20  free_block
      12  slab_destroy
       0  kernel_map_pages
      20  change_page_attr
      12  __change_page_attr
      16  split_large_page
       0  alloc_pages_node
      24  __alloc_pages
     284  try_to_free_pages
       0  backing_dev_info->congested_fn
       0  dm_any_congested
       0  dm_table_put
       0  table_destroy
       0  vfree
       0  __vunmap
WARNING: recursion detected:
       0  kernel_map_pages
      20  change_page_attr
      12  __change_page_attr
      16  split_large_page
       0  alloc_pages_node
      24  __alloc_pages
     284  try_to_free_pages
       0  backing_dev_info->congested_fn
       0  dm_any_congested
       0  dm_table_put
       0  table_destroy
       0  vfree
       0  __vunmap
       0  __free_pages
       0  free_hot_page
       0  free_hot_cold_page
WARNING: recursion detected:
       0  dm_table_any_congested
       0  backing_dev_info->congested_fn
       0  dm_any_congested
WARNING: recursion detected:
      12  kmem_cache_free
      12  cache_flusharray
      20  free_block
      12  slab_destroy
WARNING: recursion detected:
      68  schedule
       0  finish_task_switch
       0  __put_task_struct
       0  free_task
      12  kfree
      12  cache_flusharray
      20  free_block
      12  slab_destroy
       0  kernel_map_pages
      20  change_page_attr
      12  __change_page_attr
      16  split_large_page
       0  alloc_pages_node
      24  __alloc_pages
     284  try_to_free_pages
      12  shrink_caches
      12  shrink_zone
     124  shrink_cache
     176  shrink_list
       0  handle_write_error
       0  lock_page
      72  __lock_page
       0  io_schedule
WARNING: recursion detected:
       0  kmem_cache_alloc
      16  cache_alloc_refill
      36  cache_grow
       0  alloc_slabmgmt
WARNING: recursion detected:
      24  __alloc_pages
     284  try_to_free_pages
      12  shrink_caches
      12  shrink_zone
     124  shrink_cache
     176  shrink_list
       0  add_to_swap
       0  __add_to_swap_cache
      16  radix_tree_insert
       0  radix_tree_node_alloc
       0  kmem_cache_alloc
       0  kmem_cache_alloc
      16  cache_alloc_refill
      36  cache_grow
       0  kmem_getpages
       0  __get_free_pages
       0  alloc_pages_node
WARNING: recursion detected:
      28  qla2x00_handle_port_rscn
      28  qla2x00_send_login_iocb
       0  qla2x00_issue_marker
      28  qla2x00_marker
       0  __qla2x00_marker
      24  qla2x00_req_pkt
       0  qla2x00_poll
      28  qla2x00_intr_handler
     100  qla2x00_async_event
WARNING: recursion detected:
       0  qla2x00_process_iodesc
      28  qla2x00_handle_port_rscn
      28  qla2x00_send_login_iocb
       0  qla2x00_issue_marker
      28  qla2x00_marker
       0  __qla2x00_marker
      24  qla2x00_req_pkt
       0  qla2x00_poll
      28  qla2x00_intr_handler
     100  qla2x00_async_event
       0  qla2x00_process_response_queue
WARNING: recursion detected:
      28  qla2x00_marker
       0  __qla2x00_marker
      24  qla2x00_req_pkt
       0  qla2x00_poll
      28  qla2x00_intr_handler
      88  qla2x00_next
      32  qla2x00_start_scsi
WARNING: recursion detected:
      92  qla2x00_mailbox_command
      40  qla2x00_abort_isp
      24  qla2x00_restart_isp
      24  qla2x00_setup_chip
      96  qla2x00_verify_checksum
WARNING: recursion detected:
      96  qla2x00_issue_iocb
      92  qla2x00_mailbox_command
      40  qla2x00_abort_isp
      24  qla2x00_restart_isp
       0  qla2x00_configure_loop
      80  qla2x00_configure_fabric
       0  qla2x00_rff_id
WARNING: recursion detected:
      72  qla2x00_rsnn_nn
      96  qla2x00_issue_iocb
      92  qla2x00_mailbox_command
      40  qla2x00_abort_isp
      24  qla2x00_restart_isp
       0  qla2x00_configure_loop
      80  qla2x00_configure_fabric
WARNING: recursion detected:
      16  acpi_ut_remove_reference
      24  acpi_ut_update_object_reference
      16  acpi_ut_update_ref_count
      16  acpi_ut_delete_internal_obj
WARNING: recursion detected:
      32  acpi_ex_field_datum_io
      76  acpi_ex_insert_into_field
      52  acpi_ex_write_with_update_rule
WARNING: recursion detected:
      72  acpi_ex_extract_from_field
      32  acpi_ex_field_datum_io
WARNING: recursion detected:
      32  acpi_ex_read_data_from_field
      72  acpi_ex_extract_from_field
      32  acpi_ex_field_datum_io
      32  acpi_ex_access_region
      20  acpi_ex_setup_region
      16  acpi_ds_get_region_arguments
      28  acpi_ds_execute_arguments
      24  acpi_ps_parse_aml
      36  acpi_ps_parse_loop
       0  acpi_walk_state->ascending_callback
      24  acpi_ds_exec_end_op
      40  acpi_ex_resolve_operands
      20  acpi_ex_resolve_to_value
      28  acpi_ex_resolve_object_to_value
WARNING: recursion detected:
      28  acpi_ds_execute_arguments
      24  acpi_ps_parse_aml
      36  acpi_ps_parse_loop
       0  acpi_walk_state->ascending_callback
      24  acpi_ds_exec_end_op
      40  acpi_ex_resolve_operands
      20  acpi_ex_resolve_to_value
      28  acpi_ex_resolve_object_to_value
      16  acpi_ds_get_package_arguments
WARNING: recursion detected:
      32  acpi_ex_resolve_node_to_value
      32  acpi_ex_read_data_from_field
      72  acpi_ex_extract_from_field
      32  acpi_ex_field_datum_io
      32  acpi_ex_access_region
      20  acpi_ex_setup_region
      16  acpi_ds_get_region_arguments
      28  acpi_ds_execute_arguments
      24  acpi_ps_parse_aml
      36  acpi_ps_parse_loop
       0  acpi_walk_state->ascending_callback
      24  acpi_ds_exec_end_op
      40  acpi_ex_resolve_operands
      20  acpi_ex_resolve_to_value
WARNING: recursion detected:
      28  acpi_ns_evaluate_by_handle
      20  acpi_ns_get_object_value
      32  acpi_ex_resolve_node_to_value
      32  acpi_ex_read_data_from_field
      72  acpi_ex_extract_from_field
      32  acpi_ex_field_datum_io
      32  acpi_ex_access_region
      20  acpi_ex_setup_region
      16  acpi_ds_get_region_arguments
      28  acpi_ds_execute_arguments
      24  acpi_ps_parse_aml
      36  acpi_ps_parse_loop
       0  acpi_walk_state->ascending_callback
      24  acpi_ds_exec_end_op
      32  acpi_ds_load2_end_op
      20  acpi_ex_create_table_region
      28  acpi_ev_initialize_region
      36  acpi_ev_execute_reg_method
WARNING: recursion detected:
      24  acpi_ps_parse_aml
      36  acpi_ds_call_control_method

There are more, but this shows a few ugly spots.  It also shows bugs
in my tool, I'll have to look into those.  Next month.

Now some of the top stack killers:

stackframes for call path too long (3136):
    size  function
       0  radeonfb_pci_resume
    2576  radeonfb_set_par
       0  preempt_schedule
      68  schedule
       0  __put_task_struct
       0  audit_free
       0  audit_log_end
      12  audit_log_end_fast
      12  netlink_unicast
      76  netlink_attachskb
       0  __kfree_skb
       0  ip_conntrack_put
       0  ip_conntrack_put
      12  kfree
       0  kernel_map_pages
      20  change_page_attr
      24  __alloc_pages
     284  try_to_free_pages
       0  out_of_memory
       0  mmput
       0  exit_aio
      52  aio_cancel_all
       0  list_kiocb
stackframes for call path too long (3056):
    size  function
     720  ncp_ioctl
     616  ncp_conn_logged_in
      24  ncp_lookup_volume
       0  ncp_request2
     164  sock_sendmsg
       0  wait_on_sync_kiocb
      68  schedule
       0  __put_task_struct
       0  audit_free
       0  audit_log_end
      12  audit_log_end_fast
      12  netlink_unicast
      76  netlink_attachskb
       0  __kfree_skb
       0  ip_conntrack_put
       0  ip_conntrack_put
      12  kfree
       0  kernel_map_pages
      20  change_page_attr
      24  __alloc_pages
     284  try_to_free_pages
       0  out_of_memory
       0  mmput
       0  exit_aio
       0  __put_ioctx
      16  do_munmap
       0  fput
       0  __fput
       0  locks_remove_flock
       0  panic
       0  sys_sync
       0  sync_inodes
     308  sync_inodes_sb
       0  do_writepages
     128  mpage_writepages
       4  write_boundary_block
       0  ll_rw_block
      28  submit_bh
       0  bio_alloc
      88  mempool_alloc
     256  wakeup_bdflush
      20  pdflush_operation
       0  printk
      16  release_console_sem
      16  __wake_up
       0  printk
       0  vscnprintf
      32  vsnprintf
     112  number
stackframes for call path too long (3024):
    size  function
       0  acpi_device_ops->bind
     292  acpi_pci_bind
     292  acpi_pci_irq_add_prt
      20  acpi_get_irq_routing_table
      20  acpi_rs_get_prt_method_data
      24  acpi_ut_evaluate_object
      32  acpi_ns_evaluate_relative
      28  acpi_ns_evaluate_by_handle
      20  acpi_ns_get_object_value
      32  acpi_ex_resolve_node_to_value
      32  acpi_ex_read_data_from_field
      72  acpi_ex_extract_from_field
      32  acpi_ex_field_datum_io
      32  acpi_ex_access_region
      20  acpi_ex_setup_region
      16  acpi_ds_get_region_arguments
      28  acpi_ds_execute_arguments
      24  acpi_ps_parse_aml
      36  acpi_ds_call_control_method
      24  acpi_ps_parse_aml
      36  acpi_ps_parse_loop
      24  acpi_ds_exec_end_op
      32  acpi_ds_load2_end_op
      20  acpi_ex_create_table_region
      24  acpi_tb_find_table
     224  acpi_get_firmware_table
      68  acpi_tb_get_table
      24  acpi_tb_get_table_body
      36  acpi_tb_table_override
      36  acpi_tb_get_this_table
       0  acpi_os_map_memory
       0  __ioremap
       0  __pmd_alloc
       0  preempt_schedule
      68  schedule
       0  __put_task_struct
       0  audit_free
       0  audit_log_end
      12  audit_log_end_fast
      12  netlink_unicast
      76  netlink_attachskb
       0  __kfree_skb
       0  ip_conntrack_put
       0  ip_conntrack_put
      12  kfree
       0  kernel_map_pages
      20  change_page_attr
      24  __alloc_pages
     284  try_to_free_pages
       0  out_of_memory
       0  mmput
       0  exit_aio
       0  __put_ioctx
      16  do_munmap
       0  fput
       0  __fput
       0  locks_remove_flock
       0  panic
       0  sys_sync
       0  sync_inodes
     308  sync_inodes_sb
       0  do_writepages
     128  mpage_writepages
       4  write_boundary_block
       0  ll_rw_block
      28  submit_bh
       0  bio_alloc
      88  mempool_alloc
     256  wakeup_bdflush
      20  pdflush_operation
       0  printk
       0  preempt_schedule
      68  schedule
stackframes for call path too long (3104):
    size  function
       0  client_reg_t->event_handler
    1168  ide_config
      12  ide_register_hw
    1596  ide_unregister
       0  device_unregister
       0  device_del
       0  kobject_del
       0  kobject_hotplug
     132  call_usermodehelper
      80  wait_for_completion
      68  schedule
       0  __put_task_struct
       0  audit_free
      16  audit_filter_syscall
      32  audit_filter_rules
stackframes for call path too long (3144):
    size  function
     148  generic_ide_ioctl
      12  ide_register_hw
    1596  ide_unregister
       0  device_unregister
       0  device_del
       0  kobject_del
       0  kobject_hotplug
     132  call_usermodehelper
      80  wait_for_completion
      68  schedule
       0  __put_task_struct
       0  audit_free
       0  audit_log_end
      12  audit_log_end_fast
      12  netlink_unicast
      76  netlink_attachskb
       0  __kfree_skb
       0  ip_conntrack_put
       0  ip_conntrack_put
      12  kfree
       0  kernel_map_pages
      20  change_page_attr
      24  __alloc_pages
     284  try_to_free_pages
       0  out_of_memory
       0  mmput
       0  exit_aio
       0  __put_ioctx
      16  do_munmap
       0  fput
       0  __fput
       0  locks_remove_flock
       0  panic
       0  sys_sync
       0  sync_inodes
     308  sync_inodes_sb
       0  do_writepages
     128  mpage_writepages
     204  mpage_writepage
      12  mpage_alloc
       0  bio_alloc
tackframes for call path too long (3004):
    size  function
       0  ____FAKE.Name.Chip.stat.Regi.LILP.Opti.high.lowe->ProcessIMQEntry
    2076  CpqTsProcessIMQEntry
      12  cpqfcTSCompleteExchange
      12  kfree
       0  kernel_map_pages
      20  change_page_attr
      24  __alloc_pages
     284  try_to_free_pages
       0  out_of_memory
       0  mmput
       0  exit_aio
       0  __put_ioctx
      16  do_munmap
       0  fput
       0  __fput
       0  locks_remove_flock
       0  panic
       0  sys_sync
       0  sync_inodes
     308  sync_inodes_sb
       0  do_writepages
     128  mpage_writepages
       4  write_boundary_block
       0  ll_rw_block
      28  submit_bh
      36  submit_bio
      56  generic_make_request
       0  bdev_get_queue

Not too many above 3k and none above 4k.  Actually, intermezzo had
quite a few paths that went above 4k, but that one's gone.

So effectively, it comes down to the recursive paths.  Unless someone
comes up with a semantical parser that can figure out the maximum
number of iterations, we have to look at them manually.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

[-- Attachment #2: data.nointermezzo.cs2.bz2 --]
[-- Type: text/plain, Size: 27812 bytes --]

BZh91AY&SY8yèS\x02î7߀x\x10@c\x7fñ?ïþÀ¿ÿÿð`f\x1cà@\0ø@\x17ҁ„\x1a\0 \0\0>ø¨DQ@Ý\0^Ãl\x16`˜fŠÛ\0
\0H\x05\0\x01-\x1aP*€\0h\x1e”\0\0Ð\0\0\x03 :\0\0\0\04$( =\04õ¶4\x1cš\0)­\f\x10\0Ð\x05
 Ð\x01ªª*Ð\0Ò€\x05\x14\x1aÐ3`:\0\0P\0\0\x05h\x17e)­\x06T\x01GAÒ@\x0e¨d\x1a4\0VØ{Ù@éAè\x02%p\0u \x1a
[\x1a\x15@(¡Ñ†\x1a\x04d&“D\x1a\0\0\0\0\0\x1až ˆÒ\x10šjmPõ\r\0\0\04\0\bª\x7fïUTh\r\r4\x06@42\0\0Ð\0\x01'ª¥14šzšh\x1a\0\0Ð\0\0\0\x13Tˆ„i¤Ñ¤Ðҍ\x1a\x0fP\0õ\r=CAê\0)Hˆ\b\x04\b ”Â0Œ$ôÒ3\x13SƨóZµWËj³Uk[j¿ßó\x02‹\x05\0\x15@\x01€\x1fö¿Ç\ç.\0\0\0!\0\x04€(‘D‰U\b P\x04Š\0\x12\x11\0\0\0\0\0\0\0$Q\b\0!\x01"\b\0\0‚*\x10$P\x04Š$P\0\0\0*Õ*I\x01 \x10€\x12\x10€\x12\0I \x12\x04„ \x10’\x04 \x04€HH\0\0\x04„„’\x04€H\0I$$!! B\x01 \x01\b\0\0\x12\0\x12\x12\x12\x04 \x12HH\x10€\x04\x02\0\x04„!$€B\x12\x12\x10„„\x02\x01\x02\0\0\0\0\x04„„„ H@€\0\0\0\x12\x01\b\0\0\0\0\x1fSV­S©[ø:ýöôŸðÿ·\x0eIÿhŠ\x7fõ\x11¯úe\x0fúÖ\a<Â\x7f÷D4jD\x1dÆRTÓ†vÓÒÿðòsÃþrU5¬b¦\x7fýwI\x1c¸q݇v|Té‹­wãG)#«\x18c,eŒ°É“&L™2dÌÉ“*dÊdÉ•¶HŠ©•©“&L™2dÉ“&m2™™™LÌÌÌÌ̦S333)”Êe2™™!™™™™™™™™™™™™™LÂS)”Êfd„ɘLÍ2™L™2dÉ“&L™2dÉ‘\x11U½/^ÖêÕâÛJ˜­±ÁåjjJ¦røgr¶×‚<ꯇ·n*.‘ÓÍâòÒ\x05ËNn¹¼ô\x1a\x7f\x05[ç‰å[÷c®uxšÿ\x1dúc¯iöÝÝ\x1eêK·ZÒÍ}Z‡\x05¶\få5»Òß\x16Å*»•ÀMúfê_ú[ïžéUg\x7f
9&ôïßÉÆ:`˜ÈU^Qè¸ÑƱ™Ö½mù¥Æž½®‡\x0e˞ُ\x1c6ØÃfxXâί\x1añm®Œ;DV}gÅø·ž5ŒóN=xãѧ;Ó;(ü çÓ\x0f¾._í2ñäÓê+­*ï{œyò×k\x1d0vÆ1¿f·Vtֵƶ£8©qªç<çѝ
SŒ\f–«%ª‰"$ˆˆ‰$ˆ‰$’I""""""""I$’I",’I$–ÚÜZ׺õn·nÒU=Ö7§ÓÕÖ#ˆZó·–yéíþg¿·Oóõ¨õoD].N¥µu>ïÌ|/Åpè_\r'ÊÇ.+駳£šiÕôËLcèêå²”½;Îîèñйé\x7f‹‡oÛÄ•O§ªê;\x1dM=_ømÄá\x1ez0œ+2½gµ‘ÇÀª\x1c¤\x17Ù=ÏMÙÒzV\Y<W»£M¼-ÊôôNf.ü:8jiiƒ¡Ã‡wU4»»;bÜcùë»~î/gìôW_,´íw\x7f‹Ý<¹q%S™*3ƒßS™œÏ‡LMB/¼äN“Lj²pÂc&6†—ôXøÊíÑk^\x1eÏ&;|½§Yôøz¿bâh~«of^[aŒpÆUçÕ§\x0f§Xæ½×ѧVγÔSyCkn\v×cÊ#\x0eO3àävô6dYŽïw@}é\x14Üò±à:®½ÏÃë=g[Þéöwž¹M/K¢({tÆftá×:çF—FÝ\x19ëÍ~[¦Ÿ-\v¦ß†ß³«…u‘Kt9ªÖL|°èû4ºÿ\x0f\x1aáèÓ´îx~œ¾Kðøz8ï·™âpòþ\x1ag—£µ.TçÝÕ5ÑåÑ¿\vQå¿ÝÏ½Eߤ•NÒU9kF5Ýó\x1aLpÛ8Þ=s¶8zk9"\fo·gwL¯¥3\x0e^Ž¯³\fêâ¾èŒ]¶ü<úsÝîá¡Ž\x16.'fžîb+¿YÝÕïÉ©T]dèiìn\x1cpâÛ\x7fS»ÞB¯Wšìêc®¾tré¯L{~Ú¾¹áðñÝðòÓO/wC—Øð¯\x0ee*½žC±c‚Òe–SÒǤ(º¼yz´:²Î«ZÓ\x1eμh¤š]Ù\K‡¬·íTXâ4³öIìƒK¤õmÓ×4p<°Ó\x15ö‹\x1cóßËѾ¯w\x16óß˪’uœw<¿wu÷öÿS”ǧVÞí·<q¿[Ø;W¤êåÁo~¸q½fûcq¶qìÛ—¹ÿ…Ю=\x1fjü<\x1e=\vOC²iÆëÚµÙ厓\x1f\x1eNÌ<|¿/ºõz½½~Já}^[¼g©ñ­û»§…ùpðåöyháë:6|<;=aTêeJ¦Rty®\fªz®ý\x7f]^&=ËÑiŠÆV<=^§òz¾<û³ÝÝÈ==Ó'Øvp¦“—G³·Ùv9Þ1Úô{Uv4÷\x11§u§w	;¼>õÁ¥ÛÎöÖpÚµ(¯k\x18\x02¶úUÍâW‚®9·çB«¥Ýž\x1c˜¿wŽHàŽ}d²ï©FãÌêy Šð\òþáF´Úw˜=¢·’dfn|´¶=xˆ5AL¨©ÄÔÏ	S'³§[®•“äijFx€‰ç\x15‹ÍmMIs\x1cPW—NøƸpr1KJ\x10\aŒ¡Í#ÕyFyK¢•.šˆëë@¨&Wo>„
¬ò\x10€\x1e\x7fCârd\x18\x05Pƒ	œ\x11a<45k®ðæ¼êð‘ªn³ü´V¥)Kœ–¸zÏ]F§‘é\x1e÷o\x16ñð™ˆ\x1a?LP¨³\x10¸>±¯\x11½ðÇ6€Ø×W=¸º<Õ2 ©¤ˆbk7ž®;x\x14;v|Õ]êú»‘]?c®\x05\x0eb*ø]d«µ\>½gQt‘\fw·àí$f{Ï\a¤úÏ
\x1fÙ~Yù°û®ª‚9[i.Òw\x11Ñz'‹žÊzVDŠ.Æ“{Ñ\x1càt65¡¦‡}åj¾\x1arÏG¶qÃÜÖ"cvmrͪrdÊqu\x0e·“žwœœA\x16ï¾Z`4”^
”CVˆŒ3gi5èNEFÃE˜Áæ\x11¶ýH;\XìNm9Ûm¬µz;½ùí>§:–º3ãÙÀ¼íxîÅI¦»Ã\x17eW‹×½9Ag¦ß^ÏƵ|˜º|(zŸ>ýCùûV§0Ä`ücƒ=\x13ž9N”\rL,wåh\x18ªBì\x17]`¹A\x17|Ûck…vnnâí[^KÓ}Cô6\x1dz]ǤÓÔ1\x18>‘ÛÇ–b¬d‡˜É•ÍïÖ…æ\x18_]FsW¹‡\x03d:™\ÄÕwÔ\x12G\vT±ç*å\x04y\a]Ý|&ˆ$\x12Ž0Ž' A\x15æX8•]Õ5r¾Ì³7Ë\x0f\=ªÀçJ!œaX4.\x1f²úyÊÝBG'0cÒÜü¯¤ù29ÕèÄ\x01\x0fI¯\x1cÈUKã»z¯¢ø yZß¾éç¯*¯Ÿ}[«¡\x06A\x1d·Â<¼”ùypøm÷«\x1aҏ\x15«0ÃvïÂD1ÆŠ™š5TÈ¿.\x05Äj÷\x19,ÎFFmÝU]QY!:phܸŒ+ìû\x1có¿\x7f\x11-·­î!+\x126üýüFLÜÌ?—.õ‘îCùFÌ£.ª\x18Œ\x1aŠóã©›¼7Ìz>ÿtD‚¥þ¥
D\x7f³ü1þ|ÐQˆ¾Æ[ÌÊ&¬£I\x15Y\x06™#&Ú$VŒo$\vXªÚ±Sÿt3x¡K†Q4Ù®\0±Mäpphã5«µ\x19“mƵ§\x13…™ªŽ\x18ZÓRµŽ0€·%S2À\x06ôÑ^[\x18†ÆÕ4´°j#*Ì\x02\x1abbÀÓ"ÖÛ¶‹\x12FD¸ß\x19¾\x18«X5­P,ââ‚­¨Ù•*›ãKŒ#LLÁ\x15f^[Ö¸×\r·‰7•70oZN2­+\x11QÅ­PhavR•g9\	šÞl­rD[yÜâäw9Òsu[™\v\hµ™ºš·\x11Æ–ðo\x15¥‚‘k\x01®5½ëŒ›Ûm™‡\x14²’\rªA”˜•d”ᶵ‡\x19)W\f™# ¥†%¡\vKK[Ò\x10ÚáRáJ-ï*¸H,´µ¶Ó·mné\x1a¹¹¹Ú%•£µ
Vµ½«y¦7šÌe\x10Û\x12)¥„\x16e\x13‰¦›¶jp³{o\kIª¤˜›˜Ì,ʵ‹\x11¢4Ò’Ê™¦*ã\x17\f\x1aÇ\x12ÊÒ\x14±q‚\Fa4W\x01…nY­ñvkv´ª—\x17
U®ùÇ:êÜËjü©q«Žu¬+\x14£•\x1a¤©¢BÄ	Ç%jÕ”p¹š&ð¬ŠjD\x1a6HÄ3"Û\x15¡ŠiF#\ê•m\x06µHÚÅ,¢\x19\x1cJ+\r±o&¶Óy\x0e\x15ûÄC½(”ü–Wç%
Ÿhˆe	\x1aÊ f@¿R\x06* p¥*À |”¥X.2̨J³,Ëñ¦-df\x12I}\x14­RÕZ´·X\x18Ê\x11$È‚Y‘4ŒÒ™‚0Òi’d™š–BIRÍ"&-&³d’%\x14c^[\x18ǹmJ8ÄT¬Å
æ"\x19pJÉ)MåE\x0f\x1ctýŸ~?]ý=wÞJUýt÷ö÷ÓY‘òÖò­7›6³ß\x13Y½³\x1a²Åšµ˜®5¼\x1a·›Î	¶¬pàÕi¾0Æî3W\x068Û{¦V•¬6ÃMå4Ë6Řâ[Ô¸Î8¸k\x1aÐàÙ¼«f²q»MâÖZÕ»\x198ãVôÖe\kx5o7^[œK-Î#q­i8ânuÆ·nº‹s2În\x16Ýó¥\Ý:ÕÖ»L|ÅsÆ'\x19ÆìËLdÍ5™\x1cëyV›ÍÆç\x04ÛFÖ8pj´ß\x18cw\x19«ƒ\x1cm½Ó+JÖ^[a¦òše›bÌq-ê\g\x1c\5hq[­àÝk\x17^[jÞMcZm–.8Ózµ˜®5¼\x1a·›Î%–ç\x11¸ò…÷¾­\x1fyèþªjrŸ¶2Ç,icïtãK
\x7f\x06W.\x1aûÝ\x0e¶Ú\x7f\fZŒ7ei\vh_ü¡\x7fÕ\vª\x16пt/Ý\vý€úb•Kî˜ZÊ‹_V
E˜VŒ©+l\x12ÝD\x18²Œä\x1aXK"X$³5­)
̨ÌQ+\x04Á\x0f¾
Þ$jÅ"\3ï—\f”\x13–\x12%–Dª±‰k\x12\x11¤¨Å\x125mÃb©Ã
Ùe\x17\x19)5¶£9‘h˜E,Àœd+L\x15s\x118Äq³‡\x06ãSG1¥m\p̘Ü\.^[8MÍ\x1aM\x1cF–AµqÃ2cq\x7f’¯øbM\x06Q`dr\x0føIþuLÓ\x18bÉ•;B`æ»NŠÕjolâÀd¤b¥Mp³•Î´oZ[ÖŽ%^[q7‡n59Êý±pãF˜Æ\fÉί¶¿ßÞü‡ZG{Zë™çøpœTæÕ¤\x7f|…9È’Ì	\f™X±TwÕ<]mÿÅÐä¹¹¹å×¢™&\x19\x11LÿPÔFÌ\x19‹®<afS£|\rŸðˆòRG\x19K1*;´^Z51ai£•Ûª\x1aL\fŒÏVøòö?¡œæ\x7fïúæ>Z~/Y}shщ½±‘U5b•Ø‰ZÞ–±¡–3\x19Uf¼÷$•´¬^[Ä‚Ö\x1aÊۍík%p2•½j\r,e‚˜%•`kƒM㉔×\rZLÔÝnÔá˜ÕÆdÇ\ræŽ6pÞ8™MpÕ¤ÍMÖíN\x19\fLp÷\x02e\x15=5\x1f8Òdk\x1eðŸ!G¹þŠòÔxƒº$:äL&Vwï¯\x12ØÖo[—*ñD0ðROÓCf+´Ž‘\x14Â¥uµ}øÕkC¤ˆ:+íïý?»÷Ö÷5–gæ_†›ÇÜgß\v擽X•„…ˆ;2’y1\x03÷ìù\x0fhŒ\x15|£Pê´Ô4º";b§j1\f\x06KXƒF(éZÀç\x12¦\x1f\vö©ùlÚÝNaÐŒ\x0fáQ¤˜\x06ð0öoCi=\x17\x14zö=s\x14 Ì—ß\x1dðµ­UzBc|jµè›Ö—\x12 þe\x15ÆøÖL¸VùfM†Íê™Ç\a\x16nZŒâ8áZÛ2l5·Ã2l6oTÎ88³rÔ{\x0flDý•Ó…¸Ú½R\x7f«dçž&¶®‹·6Ã)¨Î3a”Âî¨Í*9µ•Éâ|O“SSG•GE×çÅÜ\rŒí§IÛÁœpâoƒ;\x15t\x15âˆcµ½³›v¶Í؍\x14“\x11ý»Di©·ž\x0eò‘.pÌkFŒ`ÁŒYH«2®ô˜Öp¥cXÎ\x12\vKN5N\x1cQ%§\x19\x10ÕV´±F#\bajp¤8™k2ccŒ3\x18ÖÚ[eN4e]k¼×Z›£K»šïtiwWj%­´¶ÊœhÈÜâî¹:\x1d«RѪÑt`¿'.YÙvÎCX\x15¤6pÂ)x—vK\x1c»?õ™˜ËÑQþÎ\x17ZÆ;®§¥Ókfîbq
Éy"WH„䤝\x03KÂëåq:]y\x1cò¶\x1f»ÐáG0Æ<búÖ–c2ÍìBÚD·…¬·™*&[oRQؐ·jÓF£K‰q¥†î&\x1ajÖ8á£Z›âZܵ¥†î&\x1ajÖ8á£Z<"x<qåäÞöì8vTtëĈ;#¥”²ÈéÂBé£^[–hÆ\x1fÙÁÐèuÑ£‡wBm#¥ÚkÌu[›Ü\x7f¹©Øê÷ÄCÚ@ÿî\x10ÿˆ#þÿ÷ÿ“þh>ØÿÕJ³îþÛþ²ý\x7f¤½/õqûn#ÒÊý‚½»ÿÑ\v¯D‘GüüièÿÖký?ô\x7fÙ\vð¿ð’œ\x7f'ç¯ê’Wå*z½ÿñR®oùûoÎ?
Ãü¿H\Õ\vÒï\bwwv#õܯò}ê?”/üú?ÒÅü¡|¡}|´ˆ¸¬„?ù„9Bÿ¾ËH_d/
Ù^o¯‡Úÿº\x16$èˆ¿Ë\x7f™î¯\x10‡\x7fD/\x0f?ø\x7fT‘û_o;‰v8÷~Õ\x1düÿŠý¨‹Þ\x7fˆQò¿äª<b+ÃËþ‹ìýн¿\x03û0ÿ)ÿÚÏ÷rû^[+ú¾u=×O\x04/YH˜bª–0”XÃ\x19EJÆ
\x1a¼¿éx{ºñÙ£ò»Ñ²è?êü]\fcþLa\x7fûwÐr8]«©·þÍG\x1e\x19!WWû_w9\buZ\x1aOÿ-ˆ[‹\x18ÝE‰‹Ù¶ÙcĤ\x1fþ`Ðÿïjv^\x15î¿ÅýtÙ9tnz±»Ñ†\½\r%Ý8/{;=ßw+RU8I\a\x17íåo3§ãý>?ÿ;~˜ö<îG\x7fJ!ÄüoÓq\x15·ÃQ_s\x15ÊÏ|ff´Ö8œá råiÉÎHŠ½u··âóÜÑ \x7fâ"º\x1a[ˆ­4uiÝÁǵuƺLD­O\x0e¾Ý?Üètºû:º^[®Bw=Ö¡<\x11ŽÄ㯆¼9ÌÍýwq:SÜ<]ôiu[ÑîW–IXÄÁ‹ª˜t+±ü.W^§ø'SòïÒöŸfÏKÃ\x19w[ÓõÓë·×¯¿g‡Ã\x1dµü²¾/YÍêÆXÇ”\b)9)9\f\x10êZ\x03t\x0fY€\x04ÈÀàGË„çüù똅'ÛˆzÏ[éþî/‡ô:\x17Ùíó¿ñéITáíû£òð¤½\x12÷<óû\x1e:÷Æ1íõô½xxE.="®8\x11ˆH\vÌÁàM”f\x1c´Õ\b|\x04\x01@¶\x06Dþ7\x11Ø©úòßfœ{¸þuöp¿Ã—ÞLLNúªÓÏWNçï>¿«ûÝ<u;ûkÎf2?3\f°Ã\x17·>ÿ=oc³®\x7f\x7fáÜ\x7fLãÙÔëôî\x1f¾Ñ§¯•jßáû¿3|1æŸN¿™*œ¿ƒË^[’©Äùõ?¨Ÿ\x7f\x1fG\fŸÃ§¯ôÎϦ¯\x0fÛ¦ûüyÖÿn°g~Ç\f>º×ðºp¶çO¶¬g\x1fsMnJ§Ã_šþ‡œºÎ®¸³\x1d¾½žnýkÂù4®ÕŠž_/2¨¹5iS‰÷vw¼1¼ˆôwy‘KÛÙâÇç<öâ—VU\x1fÃ\x15ÉTÒàÛͳžÌéáÃ÷^[öüô{©:/§O§\x05~Ø[F\fÇÎBªç\x19©Ñö³3ã\x1d]Íö7q{¼=ïÚ£‚«åñcâÛÕáùïè¹rÛ(éóñíó:;:—y»øù:þ±®6õuõ_\x7f^ïR—FR;ô_·ÞïypÓ*:Ä}ÞîÎõ;9vúÕ~?¯/Nµðý\x1d³Ùû½}ÿ\x0eƒÄÚøéGHüL[t\¿\vÏã¿ÆygŽÓ¡Ù>q^þž\x1ck=9Þk÷<RTß i†RTþüjã1Ž\x0fŸo“©×Ô»=4gë3Us€\0\0\a-sòyòêÖýïÃéûŸS4îò卽û«÷ëÏ\x7f»Ãèãáý\x1etááËM\x0eÇñ÷¶~½¾¾}¾'™“\x1d”ª~ǯʸaåóúý»³ˆã¿Ëw¤ÉñᾯÝý1Õ‹Ö»}j6í¦\x1e\x15Ø秥ç¹Ôòü/Æ-š\x18ÅÚöhÍæky˜ÔyéiŽtð\x15SWÚyCáÊÅlê>oÛówK¥K^9xðø=bA¯K¥Œaäþí²\x7f°®®¼OF4þÛ~\x19û²¼}f\x1ai§âR«g͆1Ã\x1e¾\x7fˆÏŽ]«ÓòüOÓ×\x7f\x1aÖ»»Nƒ\x11¿ã\x1d½]¨*üj¼O/Äê½_‡§.Ñóß»—;ók8wñ­?õÜ¶óZsÉëæ}W÷|íí'\wñp¬ÉJ¯gðß\x0fWÃÙÕ\\x17'‡IëßžnÒ\aÒáŒm¦ša•ûž­¼On;ýuûŽ‰éøõkÏfêí‡Rv}Ùn¶\x1cbjpÜÓ³ùno]Úuc«ƒÌà¤\x1fuö}‰ñ;&\x1eŠÑZy4^$AÚ'5\x10b5,§8ªªÑìÑÃ\x05³:ªèt0¤›úü<FzÎsŸe$ôèçíwcwC£ãåÿ¡ùœþæ0ùW¬Ÿ½ç\x1f\x1fˆê÷_†¾Á‡†•ñ¦×‚pº¿­øû=•÷0®¬{8}dþ\x7fxõpöuGñ?SÙîôITú¯…³|š”ßÇ/\ry «.ÃTªšú?[¼tuï„ÇO¥idıË_ùUiu?'G»¢y5¼Ïð¼?ŸWé»±þF¾ÏÃŽ¼kOÖ÷õ?©­åì1¥ž×›KCkU8°˜¯\x1c¾Ï§çè~\x1fÇg©öûÏgW×ë:±ê‚žÎžÔ×Ã\x7f+ê¹\x13Œ2SÚõýÜËðõÌ|'_O_ŒÖÑÉæúåI=çWïÏU{6ŏcÞûÕ;:ºþ=\x12+þ}}±¯\x1c]\f}WZJ›~_‚\x7fÕòöüÖaY)&@ņGÁX\x7f%¦ž¶\fc\vO7\x1eû\x1e\x17VÔ—[åÇ׺\x1e¦{äû#=úfß9˜ÌÌÌÏ_kF–ÊIÂøÅÕçñ|zûüvÒ¾,]Ì\x19éé™ï·îîõìšO>\x13K”D\x1d\x02q4\x06C\x01	ÄÅ„‡@b{O4DD¨PÄ(F=)ž>ùX°Æ0±Žæ”wXáïê¾|Ü#ôÅÓ\x1dŸfÍw]LÞz¹t’©Œ^¦Î›×n£OhÒË–\x18êìèëLL™4åòm\r;ÉTþ¬á?Ž^\x1ešz1ä—\x17Ã'Ã\x1eËõÐl\x1a¬,bÊÙjk\x19…ºôÇde*§Àw×Xôž\x1d®333333;Î+H}×ÊÒ8êÚé~ÓÀÓ»tª\x1ai˜ÓL?]\x03m‹¶ŒÏÕdÝ*ûüÜæ´ã:t'·\a%òë:¬ÛõÊôÇ\x0f-;?£GÆ߀{:\x0eîŽòU9óøôêé×ûPõNÅ÷th¾švDwÖ¥)ìxëN¾gž:Ï´GËîz¯W¯áé;ãêôŸ¯<W‹ÑwLO\x0eâzðÓO„ÛFDÔ¯~ÓìÔ÷|×+¯†k¾æ v‹xŒ¥^Ž ØL\x7fO랾Ƶ§¥û½}/^6÷zW:Öm®³¯>ÓæÇðþ\x18iür_	Ÿ1\x14ÊTÆ*\a¯<Lvf8~åe6Æ9ÏÉËMc†–\x1acT´Ò4iŸÎ4ü)kìü-\_\r)Ôa¾ü;»\x11·\x0f³M:1ÜÊã%4b§XÅÒõ±åý›aËS«\x1f‹¦C«Ñø	2¦¤ª~‹Û–˜Æõ4Þ7ITÙn·H†—SÄ«\f\x18¹ž¦Ñ²Õ“\x18O\x18Ìdtn‘×*úÆe;2k1&\fe+LkA©8\x1d\x15:°bÅ‘•ŽCTþ\x1dԁÔê¹åENÕŽÒ{àFa3\x19Šc\x15öÅ\bv²$)ÉÝŒÊõ´¬\x17ٍ5;ÈUá·×àCã
®¿lUi\x02lõû¾Ç.\x1frVÖ°Èú1ð£jvcàí=žÝîƒã8hêÓ%$fG†„KË\x19ÿ¾¦1Á‚ ì`ã\x06¦_Tºz¼Ç_’Ûþ(ZH‡Yç»ÍÕ;ã>ê4ë=+3°\x1d¾ôW\x16$Œ’Ê(>*Qu ëÄæGdê]¥îÄL0Š2d±2¬°ÊÊe‚Aþ‚°ºØ6É,:rôÆUŒà<\x14“´ç\x1eV üÙßõ‡ù*9´ê/\x0554ý—½á9\x1fhôG·´»xTʺÔ̦1Œ½u<Q+ªmŒX–ù|Ÿ\x1eI}0Q¬“‰x²¼¤í\x1920ªÊ0Q;qâï}É\x05ðH.·\x15ßWd/XuÆûû3õÒ—,ÌÆ\x14ïÿ¦Ýø4k&™òo\x15{Ùc&c1úêèáÊ!¡#îõ=–TÄ¡_Ã\a™ÖÒp…CàªÑ¯àõaôðUÕË뙓‰.l¬š²nO\x17ԁi\x14_\vRU4c³‡Uºþý\k]7ŸM¾Ñï¦ÜWÛ«´ÞãMíÐlߦ‰äÙÃ\x1eí½{frrÛgN\x1f
IŽK¡Ç\x05$Üàø2ÉŒeä±eauhWŽµÁ²‘ô¼kü31z—ÀÕ"º\x18ÏÚdÔVF\x18¡_Z*iŠ»\x04²ø\x03æ‘é’®c‚\x15yÃ2=ÖWÇ7D\x03}ÙzDø9»ð‰]­¾vZdzaù¿†4:ÖL±Œ¤`0\x17a€|el\x19]!\x0fvRïÙ¤…èÈ°\x18ûrj\x15´eÃ5aº*™RÆ0\x0e1€\x19u\a†$Š¨\x14\x04T\x16Ëeù"¤´:k|·Ç\x1co©‡“Ýþ‡¹×ñDYw{-GËËLüµuyu/Û£“–LœF­
Tã\a\x15.Ó\\x1c®©Po߬êp8££¡88îÚj\Î\rÛpŽ.+–GdO¡XA‹\x18°—Er§Ãn"!ƒ\x16S)\x19.vØÆÙýï^[8ë©ÒJ¦£¬ízS]\x177—\x19#ëMïZŒc1Q­4ÂÜ­DmË\x1eN.3\x0eÁ}2ˆ²Ë\x19í\x0eÙVe_†=\x19‡î’2½\f°ˆ1trJ5ø.\x14Ó\x15—r"sÍ\x1e‹Ž«6,º>\rÉTé5_ÃëLÁI¬¿\x06_'^Ã\x1eäwL”W\x18±Š±‹\x19	ZeªÚÜç$÷5Å%\x1dMs*LL˜5¦2™¦f\x1a†š“mR\x05¬±’Ël­i0IV%\x13V¯6¯)³4“dšU\x1a_cgªhþ\x19;̏wŒHþžx©ñúµ/++ã\x11<:±XÅÃonÆ“k\v‰—w:
©ÂÅA…0?¤Á“-ÝžôŽD§\x11ëOLË&YÄðsÍåDìíeÄâãm3ð•S\x19aŒaßJNÓ\x12?&B^[€0²B™“u\r,\x1e¯vžÎ\x0fWyÒ‚¯ÉÁn½*ҐÒõË5=½‚ôéY%SÌGÜó׋y–œL–øü±­ŸÅ±£’ïªÖî[õçz€‡Ç¶+\x18±Â\x12Ûd22\x04„B zÃá¶K\x05\x14à–\x19\b«\x12\x10`ˆÀ	’X@b1Q¡X@ÿÏ|ÔsÏB¸˜ê^ÈÛÆ\x16Œ¯¶<K£öçÑ«'ÙÏ\x16\aÙ«NZÆT\v©‘¨ZYñ­Ëvm^ó\x1a]n:îáëš—£ÕªóW“S\x1cÌo\rìáY]Ý~yxLÆPÁ‡*º½í^[Ãk‚Ô}6\x1aãÙ¨Û}0õö\Ñ+kle}ݧ“ì8ž+\x1dôuRºIt`ı‘^[Že¼;*·\x11º‰øc=³4Ÿ/ž]\at\x01•·«¦\x0eU*š\a\©r±ãR\x06¿«F}þÓsƒð¸Ùn#2#'\x0eõêÕ\x10ø¨\x1dãË‘\¦t‘åØjâªPõ'ûºv¬Etèžß´§Sn\x19‘\x15c(ªe~\x1e\x1a³7c\x18ÁŒ\f¿\x16\aØ­I¢¾‹,\My·¨âÇ\x0f9óv®ÊH½êÇ'K\x18Áæg«\\x1e\x14“ïü—ãØšÁÍ/p᧻¦•=Þé#JZ†¨!Œ@óÏÀhN‡\x18ÈÀIb¨EX\x11?iàñ‡1¬WU\x1cý´([^K—E¹Šë¢wé(.nnˆÙ•ÞºSm¤\x17–×K\x10Øë]·:NÌ«£'F5Ã\x1eξΝ6î;9zv\rׄl›féÕÐéÚª\a\x13®8w]^[œ+†œ¼\x1ez³žTæÇŽvïO\x0e'#¡å^‹Šáç“W5¾
ÚdìØ°,\x118^[8\x04P‘Ž c\x17¦‹Îù\x12—<ö‘\Ÿmq\x03‘´o¨\x1c‡@ËìTæU\x0eѝvá\x12†ñ7’‰G—”–UÀE¡\x04H$\x12;)]u›]fRy[\b»†\f,rÐ\f‚\b\f\x10v8˜ç)7ýC±Á¦†¬=sÎa§Ç78q\x1cm	‡\x1d\vY<\x14V\x11$é{ÄCEÏ÷BäîíÖÝFÛ­é«¢î…Ôøë)\x1e\x1f
èiÔzên½½ÊÜÊ|as6æ¾\astpêÔ¹äM³¿IEiqñ¤'‡Nz™ŠuѼzqin8yxãº÷ˆìâ“n±ÐãY•›á\x1cöµÇ~5¿\x19háÜiÒU\x17¢¦¬Hrc4ýŠ®Í¸]—wfHó—>]Z.ìc\x1680êμ2a¦¼^[6rÆ«ly9;GWYÕÕÇ.‹ž^[s§~Ü›»—Gk\x1c4’\fRƒEŠ¼öéèáƝžü\x1c¯\x0e!vìîÅ`g²w:óçô5×®ŽÕ=‰ÊrôUuðŽ­\x16t4»ÕÒ$Ï:2 ·“»KÛÖï'\x0e:÷\x1dVšå±¤{Ë\v\x16QÄzÜšÙÑÃ;LÜíâ#˜YJq9Gi®ÌÍ(‹MNÄxuH«,™feŒÇÿ\x1a¨»CÙˆfV1ONx^[)\x1f:´ò–ŽÃ<´²ÈþZ°Á³\x03[дÝOÔï§Éà–öt˜ór¼\x1fç„̈ÆŚ¢ãú-:;\x16)\x0f3¿‡n\x18Ÿ'ÓéÍqêÓ9ÌÍtÌÍï†÷™ßœÎŽ:1γ5Ò@Âdô¾‹¨à½µF‰$ÉBªâŸ±¢\x14õ±vÏ’«*þ\x06#†\x17Ý\vî4¡{¿ÍÑÖ#Ÿåîô½oáàû>nôGLM²µE\x062dv«”‘èÔñ'1ŒàüyˆõmÅÔ…üL,ukY2\x14ÖMêÜá|\ÔÂç¤Ú q\b˜T^²Šx§få°k\x14³\x1fδ_mwnÍåfM_mÇ\x1d]«ë¤‚ã%è\x18‘M>Ú›²`^œu¯£\x0eDïJíçËŽÅßâð̲öÖýx|ç;²Æk\áµ”é8\x1doðÅò1Ñ3H\x03]|V]£³C\x18Ö\x12xcÔÅ\x05rÊ–2)\%Á“\vLi#­zR_½ü±ˆõqa€\x18\a¶ÐëÍ\x01#ÖçY_\0­\x02\x10\b^aã\x04ôËE߶©\x1cÒs“UtuNns6êâu¿›Ÿ_Ž+£¹ôÁ#ïÁwðö¥xôŽîÝ"4ò*\x0f\x14Ò«¼ê°Å‹\x16BtxuW\x11ŠÏ5TWr•0¯r±RF˜\x18™\x161Så˜Æ™\01‰†*+Ó—;ÞŸŒoLc:2µfaí\x11\r¥òmM0þµèª}ÕYÑ`uGv*Æ4ÆVµ\bµY2™þþ&¯OT¯€2zbj\x0e±x£Â“U$ôuã>°Ì±’Ó\x17ÿV¦¤ÅŒ˜zÍ\x1aÇöÖ¨Æ7­+&L3œ«K\x19L“ K\x16÷½Ì²°Æ\x13*ìõ\x19ö/\x1d|\x15G\x12\a-î*Ζ"\v&?†ã¢¹®Æ®\x10­¯2C¿®tb~2™”Τ°~ãj' Ãb·‘‰PÉ»¤Ë+e©mºµhÆKxup»â\faW'«F2ö­ýüqy|Ñ\aVºêݯ*u í\0<\x1fÅ\x11zݝ\x1eJ¯ß*ì`-êž\x0eš]$WƒšûCùgYÑæ:\x1d%‘Üô\r—F\x7fäÇB˨Ì\x18Ó1••“
ÊȲ0Ãs\x02&½RU–Œj@Á¤\x1d\x05i"\x1a¤b2Ä¢e\x11;böR•bV\x18°Ã\x19Hþ%e\x01jª\x06\x06:´œ‰˜Æc)\x18TÆ2FX°ª\fŒ˜Y^[*©ªÓlfM=ÚN|µ—†µG\aðÌÌŸMi{pÍÙ¯=Ÿ;šèÞï†\x1ažg®Tfz¤£)VD1ŠI“zð_1\x1d´¯ŽñwêÕ»Vô—:•æôW ®O%pjÕªã\x1c®f£I*.dÛL\x1cçô1·ªÑ·/\x17ᎋ»\x1fÑrô»$Žf+猪˜\fdÆC&˜51ˆÅec\x060¢\x19^^[m+{±$\x1a
—äîtŠîo‰T#©•\x1d(éٝLY0¬«ÞÒÓ\x13\v\x1621†3ºkXîá¶aÔWE\x17£%ê…í«S\x18Ó\x12Ñ’“Äœ´ý®$Ö5mªë\x1e˧ Ç\x05ïüå@ó\x15Óa ‹\x16Ë&1cöý7m–1¨ˆké\v1¾YÇ\vfæ†ôÑAŽ5Ã\x05Á‰ÀðùÆ0¥¢¤™‹âáS‚ò{ß\x1e¼uˆ­U/;\x1a?\x1c³\x12v¬
+wX!Ò7™‰™¥ø¡lßšçBê…ºé6rÑÙÃa]£×ÙŽýµÕÍÇ\x1d®Ê8¡j©´‚åZí=p\Lwtû/Ó²\x17t.Ù¿gyŠÏ\x13T7½\x16,`¤Öp›tXnÇ3gÚ:¿D®§ˆç»éK®Rªf,wV<55RÑÐÙ óÌ•Nó\x1fÈÒ£\x18¨þnþƒã/Ök¤ýÜ‘zÇ1ìö\x1fÑ“®KíÉóŸÉÔÚéq½ŸË\x0eùÔ;\x18—G\x1eP½,2Ó\x1ff§$ñtiÅu/díýö'Ã\x18¬Œ_Á\x1eˆð꯿ëM1Oɇ†ìÃ\x1af™®‘ë‹N\x1cÔÝm½\r†.)áé÷[N\x1dñ'õ¸c7èÅ2t}ãƒ\x0e­Hý}ç£+ÍÌÛò7Ãl}”õK°~2fgÒô*©ø\v,+\0,£µ+i\x157»DÄâÄ>́¨\x03%,|éÁŒY}ŸµK\­ÐU¶ç¤ádX±5hÆ6„¹9hN\f®q‹,¶{±J\x1dEU|æ\x04õÕ¤RÉ–²P4°,j@Ë5XYC¯\x1fo\fBê»”ªpè­9ÛF1õã_†˜¸teý*4Õ}+÷®’?wc\x18ô®\x16^[1£\x1aiÀâcKá÷ôKµò}Tð»\x7f·ó³ð/Ý–YŒŠë)3Ë—Å`ÜÕcK5Ës]\rͤ¨µÔÝ-\ãY­oUÒB­ \x1fœcnb<ITÓGW'\x12An–ºÙÄW3ë\x15ôJ‡l¤ó’•MŽ.>ó±]èï§^“\x15ÊW|Œa¬_\x1aÐÖö ãï^„íj¹x$†w\x179I>¼aêÉfa¹cXûp\x1c©-.­ŠV‹e•¹µ¢cSÃ\b¸V\x1cL<än·8-\x16¶´miie\x014²²FbçUºÙ,–k]U©®ÕãÇ\x11ä3Îsœ¸s›²\x17Xi-\x1a-\x0e¹sZk3\x19”¿³Ã\x1aW"\v8£UMXÁÖØjöìio”dc\x7fŽ!§Eªœ£\x15*Ý\x16›ªh\x0e–Ôäâ•S0¯\x1cÂ\x17\x1eiqR\v\x19§.ñ!ªwMõN‘ ÉÂæHi¨ˆmR\r)TÌ31ùaÓŠÓªÖ¹TMk ã(%³^[§ï1ù#·|Õ-O©‹§®ŸÝeá‹âˆÈÞ`dg\x18B\x1d\x12àµò$ÌBIÂ
\x02$à„\x1cƒ\x0eb!É+¯HÿAçÝþ›ßyº®î¢\x16®òc4°õãC)ÅŠ\x7fw.\x1f£ŸfMôbpËf$W3\x14ábFÝ\x14¾¢}u\v…\x1fš\x0fKo=\x1dÇ^g˜¼Gªú¼©ÑÕ7¶§¨tÇ\x1e;Í=\x1f®ûû"…à ƍI¼›b³5¬Æœ4ff3\x16ÌÓ'\x05Õpn²µ›ÊM#ã¥yåÇ\x04êíéÕÐŝ›êèqIŒ¸R[å¸íˏ\x01=\x11\x0eÌ\x160ô±^Ï/\x16çªûß“«M:x)z®´y¬wwöɼc\x12F,ˆö=\r1Nšµpîðõµhø\x15SI’U;è¾2ŽXÅúi¦\x18´Ê´ÆšâeÛ½ò¦=™“\x163¹eŒq¦˜oK1fôÚ©\fÃ\x06›Û\x06®ñ\x15®\x19±¦V8¢lÄR¬Ê\^Šÿ;ÙÝ㔚kêRU‰³W˜Un]V?¹³­}Æ©\x15Ž\x1aj\x14\3‡\x0e$âÞk3+DÕ5\x046šH¶›!€\x18%6Ûc\x10\x18\v\x19:«q¡š\x06›/ïª*§97\x11\fIã·sšûGŸò!vb?/\x7fG•r\x18mÊëKæUkä+ˆú*{R‘ë=“ìçÔwP¿¤`wéÃ[¸\x19^~˜Ãü\x1eÏÞi/õöë"rüµ;=9ö®\x1cº\x1ež\fxuž½‘Úpk™õw²Óøw\x1eø÷½\x1e\x0f\x0e¤»|ör݇\x19#1‹kE¦\x1e\x1eqL•™\x15ý'vŸ¶y\x1fš†˜ˆ®\x16\x06\x19w¶ÖóY™­¾ÖÓ>õ¶›f%ÌH94\x1aÂX®ì˜ÄçB¶«Ó«¦Æ?n§Àú‰·Áôä›lûŒÆ?ÒÍ\aÊk²’~\x17ã"^‡Ö\x7f/ĉ©•ÿ”ÓÐÉ\0ø¢,—õ÷§‘§ó\x1f»Ò"\x1a].¸^—owíòÇÅN‘øïo_¹¶w@=Ýü-iÛËÒj\x1e)¹©Y!V‡¹ˆÓ<Äeª»Bª×mM0D»ä\x1dºò`Å\x18´éU\v³£ -Ý(‹K
S.ò\x15nî®\x1f³õKRý\x0f«\x1d—aŠõ «Gz€èWºµf\x12´~Z*·½D|åFØ…µc\x18Ƙþf\x03f6–µ‹^[m¹%¼RLÌM6Ù¶\x14Ç\x1a6á™pÏÇ\x1aÖ´Þc\x19¦i‡\rm¶Ûk2܁¿Þ£Ýµñ†tMYZÓL®­=±W\x15ѧ}ô•Ý‡\x1dMKa\f\b\x16Æ\x17\x16$5rA\x04E\v\b\0(8\x02±ôæž½|ãmMGðÝr\aÌÌ¢©f¬ÌË\v\x18\0ºÝâ¸Õ£Ž«Š
8R©Å˜ã\r&Ë
Üܯ»vò¥S\x15­j2mæã+‰¿Chhäš,—:Þir‰\âj·Np¦´¥p“XLeq‹T½\x17’ù·àT\x1e­x¥v{\x1aïÔìÖ‘U4¬Åc1ɘˆ^[ŠË/\x18Ë\x1ac"%d;ªQh­%Ó7Å`ŠbMµé{9ݬ[1\x13Qdª7i\bK\0ÈBÚèàꬔàÊ°^[i)\x0fôu·ë‡\x1dµ)T㢲ðç^[`ŠŠ_\x1c½}kkm®kƷ̘áû1¨ï\x1e¯+é\x06\x15bîÜ·Ð:LèHÕw”Æ\x1cçJ=-B¬bÐÖƶëÅWLåÄÒ%ræ»Úë›7†%¸ÚÔµ^[_†¸œ8b^[­F÷j`\x1cÕ…\x0e½wµ*p?\bÐOŠ ¸ãòIL'k.]§kÊ[œuÐéÁ~kt\x18²¨«\fXȱMS$HÉw«V©®m}^[•%(¾±&k4Õ*†LcY–™!VZ±¶50ÛI-{¶Ò1\rèZ1PÊE=‚úýß…ê/cøDÖ\x04Ät”•pÅ|åán¡Z„•öÉ\f\x18 ¯3‰
¿—ݹÔ^¹+x/ÇRV¡\x05ÓJ¾\apƒõØz^“Ó›
\x05Þ~>Ê{Ò¾R¬Å•"÷ï© ððŠ¿¯TtæûüM\x1d\x13ƒ´¬qÜ\‡ÆIY)|@©ÞÁ\x06­\x195£NÕ4´nac'úŠÿÑò屉«S»\x1aųç]\x0fÝ\0`mQ\f£¡ˆªžé4ÃßT\x13Ö"\x1d\bܨ¿Aáµôj|:wš4iž\x1a°ÆejéÏòÉH×ÆŽ|œ\x1c^[½ó®ëM3\x19õ\x11\fÈŒÆkR¿³O\x0eóm8{:ç­ŠuýU*±'Ç\x7fJÛO‹ö\x7fgÓ£^[\x0fZÉ=çô0þÜU®"8t}{=ú\x17¬Ò%\x7fs\x0eo©üœ~¾¢\a/~\x15	óímž¼²Æ^Õf`§ÂŽÿ×Úè¤þíWÙ\x18OÎ	ªù7µ\x19=»¾î•Èçn\x1aœa•C\x0e*)i§»mŦ ÐêÀÑa•¶\x01a…Œx¤^[„\x02A'\0Z•\x01²‚'’d(\fã3žýºõ£K¥\x10ê·.ÆûÞNx|jº?sLyÓ¾;Ù:\x19uÛ£¦G=\\x16¬¨C¡LFV\x0e\x1dý°å\x0epô×n·\vn£³£.¸K—ž‡’k¦z¦¦\x13&\v&\f˜Ê\x18\x18‹4ÛK4ÒC\x18°Uæ•b\x1fS(ÈÛJÆšb`2am(Z›J\x16àC\x14™TC,½õËeH¤Ö²J¶ÛdÙRkjÙ¯\ã\x15·vËfU4¤(°Æ\x14“På“Mã2c'\x1a™™¨ˆvzW§w\vœb’`Ì=\x0fA¶ä\x0fºtÂç¹þ\vòz\x19\x1f³ó\x11àœ\x14Ž4Ç…“ᏪG•4y¨ð°Oœêìø,ï\x01t2ÈŸQ\x1f´i;xîØ®ï\r6Ê1üéw§m'Š"Óí¶‰,\fO\x01ÝÝíý‚z‘nU'PÊaŒ\fYeYC²C»rTÚ_v%k&2fu²6Þ™ðªò¨¦ÍŒV\x18Á—å*p½¶ºÝ\vÎ1·XöµY‚\vêþµ*XÅ‹èûJÚu«\x1cÄ\x17\x16\r ¦YfYZ°,ÌÎliÑ©
ºÒÏl ,ÉÖï^1\x18|}/³AF´eK&PÂóº"ë†ÝånÅ9mòÕ½údG‡LY{M51¡§¦—\x15¢ô\½]žŽ”—Y\x10•m|\x14—\x176­HG4ã|Uµ­&š½çk§\x1dûþÎyy¼½¬]éê¹çD9ÖõšÉ¬Ío3q\x10֏\£U½V—\x19¸Œ«5­ñ½õ5)i\vÒ¹Ñ:1uÛS19Æaj™\x1d?\x1a1µœ\x16´g:Õµ®2ma·\x0eXŠ©è¤\x0f†v\fpÙ$?yÔö’ë4æ¶Ð‘—Tb<BÉÚey<_/\bÊßnkN,Cß\fb¹f1ƒmDá_v\x0eÇçSj›ÈÕ Þ4úc0r>­O‰Êš\x1e\x195\biݏ#ep|ÔJùÈ•Q\x12jÖÆÚ˜Éem­Re ²²ûÊ)Ý%¨ân˜9\x18ñ0\x1fdFfTÞµk\x14zfcJK\v&,,ËNOG\x01Å’‰e\x1e\x0e¿32®Ž+)‘ß*­¦\x06\x16!¼-vh>©`Týóü1˜åŽk3Ç…ŒUåªVF{pøŸENÒˆáñçþL‹\x18\0>åðñïGRWÙåí\ræ'1÷ôvt{\x17Á§JFËo-ᝦ
ƒ¾—d¯ïT,\x1a÷ðšõ£>ôæy3±~­Ø¹RoÓùZø\v¡c(dömS	í*š¸amHk)œ+‡	"æËn|3œs㜩nÍĹ-ÌÌ2š'\x12>Hñ@]}9õUv®	FXzYÕÕ)Ò¬D®q¤¡’/g\x03ŒnI­«ebµj×I!8Ê¡·Þ·Þa|Y\x15\aZÁÆG\v,05XšY\r\x18ia‹±ª¦–YHË«\x188pÓlYTªÄÄrÛ‚¿‡\r\x1c»ƒ\x15´êÁ…ˆˆ\x02+†:Ñ\fØ\ìdÔ@ÐkF

F\x18m$ùQSštC1\x04Çp™/ݐ3\x18d"	\x14A<ë3†ùVDCêitcLc\x1e죘tùu£Óý÷\x15BÉHöâž]z|½|:8sPA’pH8 À\x18\fxÎ"D\x03=Æ©Ö²\0¶s\fí]˜ÝÏ&¶ÎúVõ^”¶ã®Ÿ[îlÊúiï\x18åÏ9·kÑé*‹¾Ý)*\x7fg^8§©Ä•Oï¾qݧݡµ×ì~\x18âd¥M§õiOw>ƒf™îl6L,‘±BĪ™`­\x15“VkMZÖffšÖfŸw ;¸\x12ӝ? _ì¨æÞ¯š­}\x05²\x11\x13à¹|3Û²­l¤œñ®Œ¸óûù\x1f\r4a\x15ˆefTc\x17¯F‘ÙvÈŽôsZq©ó«óéúÌ×\x18i7w³J’›9zu[¤–R¥c\x15$ü5¶+dö™wU\x0fI‡¡•\x03SPÐÉ–˜©‡#ŒU?<n^[e\x18aìeªÈµu8Âë|?þDC¥;Â\x7f\f•2b¢X±hûÉTÀ\vÅa‡æÂÖ	•x˜hò¯w;¤ïô•^:ŽŠ‡ïyKÉO·j\x7f\x1cN\x17áv&žMU\x19\x13ªsݵ8cìâ½ò©™%/¦\r\x18í»\r¤ªdܦ2bbÃ\x19“mSF4ÅyÚ\x19XɉŒJÉÓF©öÅÝì\x0e\rÒÙ§\x0f\vîÇÿ\x11\x10Ç'Ý’5ÕLYg|¿Ò…•MÃú/\a>M\x123*v&=\x1f=§\c\x18^[Rj€¹É´\x03ÔãÕðçjI‰Êcö\x1a{)ðà­˜c©¨51ƒÕãoW\x16‘ɇÞL¯\(,Ë‹2Õ—îYB\x16YKe‚\v+Ò翘‚ï^©\x05ëÇK<}÷K7ønâÍÚê ¾»âÕåqrjE.m\x0e^[G5ÝÄàéˉ*š%¥694\x18Ê¢®k—.úíÑÇ\x1dRék&]R\v×.m}-|®\x13ž‹@SµËSFŸ3ÓŽ\x168r놎ZuYI´è\x03Ã\x10¤²2âÁ\x10p꜂"äh=ä\x1c©8'\x02Î	\0í"Š3\r–ëBA32ë\x14,{ëP#\x176ݼ}\x1dÐ1f•SZ¼I"–	À q\x10I!8Æ
\x05`D ‰\x05%G˜K¸+\x04\x12A Ü\x12V±‹[Î\x1cõäf´ÇÎ;!vžŒ]ýÝÝÞ/nþVú±Ò­ÈUˆiÁÄá\0âÞ­¼à\x10€’sŽ\ gV89¦™Ò¹žÐëëÖ7Ò#¢o\a\x1f‰Ç~V1¬æšëÚ¸º¹"7’U;Ú£©‹"7^[åÇ=ø€4¸8dsdΘ\x15S”·26bèåÄ7-ÊUr­ÍÆldÉ×^["§]rµ[uË©ŒÒvuo‹vœ8¾;;âá­Ê¤ÕwVÕÙ²:\x1dw\x15m\r.Ã#
ªj¶æ.+^[W‡=øpºe:.9o¦Îª9ÅôUk©ÝË®[jçà=/d÷%¿Ue—Kè]ÒPèØæYYÅ&óc«J\x7fí‹\x187Z·@\x01™-M¶›Z«-Í\x03u\x19t0Öt{¾qzú´ïãÞ«\x18ëS-/._‡áy\õ̺Ö0±ìÓU½,­k®ñ¯œß\fÇ;kŒÞ^[Û\x1aaN\x12Fœ™(­¸1©–š¬náºÌ¸cLjg
Íq”ш±¶\x1cbÞÚKr\aBáõ jiâLiÎ\x1d°ô§\x1aì\”ªtn¤ygÙ…2aëÆÀÒµXÂ`bŽ{Û³38•\x1f]Ò!÷²é¬9<X£¼©“o~0n¼Ö+çQãÞ\x15N‘\x19Hx¥,©&$˶2z·C¢½©ÒI×´•4ÿ6\x1e+ÊaË\x19)TîPIéô{N²ºDCÚ7áîͲáæfvˆÏ\x03\x184|¨ƒ¼ÏL¼1þ¦:\x153Îím\x10^ë©~¦%âñHü;6²Êu횊K\x05\x16Œf0Äæ•C\x19R:\x06«ÙžÝ1¶Ïg*øú'\x0f™\x02ó®ÓA*ºX³f2Ó¹T4émå,½T¤¦¾\x1eSª÷µ~_“‘M»?aŽÉÙ“\x15c\x0f×¼÷Ä\x03^[ .ÇÆ{D¨tödÄ÷ÊÓ\x04ìe\x1fÝÍ•#ì¯þ0\x15Ñ\x13\aò¼hŽjú¯¼¥'Œ\x15Ä_\v…ƒÓ½\aÆZ?\x13=Æ)'ò;Ñò\x0fPcÄO¬(£(U¤õѨªœg×\x19k®´ã!e^_Ö›-\x12k))`c4l°±\x13ÓOícl¢3½V¾V#õY'K\b|-ËV«-\x18’Éb\x1d÷ÔÛ\x1eh‡NÎ^[sh§,ss\8Ou\<AµÑySéNmÖ„W¾ò³\x1fa­jËçÅvÇ£¶á>î°†\x18f(N½r\rLlŠƒœ§9\x11V¥*°­bcCUÜÕŸs^îøo#ï2^[²¿\x1d;SÑƆ£ô©×O”ââ^\x18²Ï–4ÆyÉ–\x01-\x18ÓÚ·[«f¸™ÅÅ\x1a\x19óá{±S´çÛ\x7fëÌŘ:Î9Äs^[ðô•ÒéЕ¨&“l+\f1ZxÕ´†·+~õ;G§}»Yeâ.\x14£NeŒÆrGQ—U+F1bÊ`È\x15”\x13£Q‰0p…Õ­¨Î+ˆº¶á:éý±\x1f•ÖQZ,4Õ¬2ÓK\x18Ì–Œ¥50J,³Ç̪\x1dº¾9˜úÂñiúkÃzÂé4f¾áeõ’ÊYßÏÊHÉí¹´?|;Î
*Ç\x15ÌÚïX\x13³R,˜Š<L·ú7GQ=¹ýV[]LtjtŒ8V˜i¤Ô…YøÒ¶Æܲc\bRC±`\x19 ”\x14CE/›Œ\x10Á\x042\x02;üa¼Þ·šÌÍæi†¥\x15ÜÙúd×v²}Ë:t\x7f.Zuí¶ÞÚÒþºõ\x7f®lžZòú{ŽCÑ\x12GÉè§îÝ*§}ºÑî$«¡/zÇ+ÿÌPVI”ÖvÃ5ÔÁ1Ü×à\x1e\x04\x10\x18ŸüK‰·/ÿÿü\x18\x13\a\0\0÷Ì|N8V€\0\0\0ð\x03äKÁÀ$P.–ÚÊ\x0fMP\x15BE$‰D…\0\x14\0\0\0\0\0P\x14\0

\0£ hPVØ\0U\f \0\x15 \0\0\x01@\0 \0\x14\x14
\x02€\x1a\0ÉF\0\0PPPP\x01C \0\x01Ó \0\x14\fZ\04h(\0\0\r\x1cE<\x01\x015
z\x1a@\0\0\0\0Jd\x11FD§£Iê\x1a\0\0\0\0\x03UOýꪀ\0\0\r\x01 \0\x1a\0\x04§ê¤š h\0\x01 \0\r\0\0	ªB„“ÒQþ©“Õ\x19\x1adÄzšd\a©êiú)Hˆ\x04\x04\b‰\x14hÀŒdÓOIˆo–Y–fVWÛç\x02\x04\0\x02I\x02\x10\0	!\0„\0$’BH@\x02HBH\x10$\0	\0\0\0\0\0\x02@\b\x10\x02@	\b@„\0\0	\0	\x02I\0$„\0		 @\0$\x02\x10$\0\0„„$\0\x02\x10\0\0\0\0$			\0\b@$\0\0 \x10„$„\b\x12@ @„\x02\x10\x0fÝYVgf¬ÊÌöÖ\x7f\x05õjWä\x7f*•\x1eԍ‹ñdr‹*ÿr¤Ô¢\\aûèÝH<¿â\x7f¼ìéJ¥ÿ6‚ÿåD'ü±˜Ìb""""""*"""""""ª"(ˆ‹3
Ê"""""[1¦y\x04\x10K`‚\b –Ë`‚[-–Ëe²Ø ‚\b ‚\b ‚\b ‚[-–ËeE­jÖµ\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x11\x16Uš³†fùfRy»\x0eÊX&F›¯Sm\x14'Z5z¤ó*–£ÍÈünÐ˵_P…Qêó[t¶<B¯\f­Þ×ãq\“„ãUe^ƒ`à$»IÂĝ\x1fò"uQ¢|Ò%Ñ\x1dÜUª¾*íWz¾\x03›æ­¼®Õl0u6T:Uô\x1dà=ƒ¹ŽT}Ô¶\x1c\x1e\x06JÔü+Ü«È«Í{Þ®Õ1\r\x1aUÂDf\x19†e+0Ì3\fÊ(¢Š(¢¨ÌªÅf]+ \x1eÔ){Æ1±
ù…\8;ˆê|¾¯Såâwi<˜æâðÓãšùvpÆ:8h‘:Ý]QÙÈÿ«NÕrøŠK³Á‹“—ý\x1a{Ü#—rá\U—“Ý‹ÅR§5"¾¯“ONOFÞ^[žo‡\r6ð·SÊqu|6q:'CNYW±bòè41ü~\x1d—V9¼=×[†âŠâ•KðÆ‘ÃW\x164nù\x1a:EWµÀ¹´Æ¦\0±–6†—ìÉÂø|»˜ós|½ž\x1eÅÅ…TÒüÚ|°Û\fc†2šy\x7fÕÒóm|­4t¾Ô4´Úôx\bW\a'‡¹ÈòhÉ\x1dŸ.Aø©U³ÄÇpè»\x0fÍûžÓ—Û´¿7w\x14ª›_\r·~š­>Z/Ë\x1f·»Ý\Â&„iÄš}°åôÒìÓ\x1cÝ\x0e¯ÓØ}½ÝÝš{Ýï\x0eï\r­;:ºÌ®Î§â+‡\x12‰sTK\x18Ó\r::º±¥¹pÓa%ÙÙÕÕË°÷KNî·Ã&:8_!
ŧӣöôÒÇ£\x0e—VžÎJ‡K³£fD£š1é\x1ai«O‹£Ô*ž\x1d®®†\x1eì\x1e^[möôèÓNÏN§åyW†â…ååäó\x18à´²Ë)æÇ™R:¶8}<ÕÈÜy/Q\rªÉù¡ê¥¹Íá·Ë\r\f4ź±Ë—‹gG²ÿ½¥Œuqz»‡{Þ᱇¦O‡§/N\x1a|\x1fó›//åÜò±äæ´îÝíuwc¥Œ>\aÛÓf0úž]Þå£äìtc«Næ:®ÓåË»—³\x0e\x0f\r\x1cß‹†Ï‹«Ô¨:,¡\f‘ËÅÁ‚ó:Ï‘â]\x1e^\x0fáÝåáå°y^oØûp¦“—GÑÐÕáê.†žÅZt4èá\x1d]Ÿw\x06–šQ\0\0\x06À\x03ø6—\x14:Õ\x0fù^¾\x7fDs[\a"\x02\vôæ| ²üò\ÏŽà”BŽï5L¿à¬M¹^[\x15f†ÊwêÄš0°VèÈ #‚¾íˆ|Œ3\x18ƒ”VÁ\x01­\x1c3\x15á\x04^[9¢Ê‘\x16\x0eÐùuêíVÅ«´BÎ\b€éªÀV8Ò\x10%›iŒ*.â\x15䧜\x1d#¨ìvÆ\x10Û±ª°†	°å)ÇJ
±Œ	pR^/NÂ\îØ…\x06¡éQ^6#\bA+Æ`œTl('-ÆÙ‹Uù$Æ9½°ß×ËŒV‚ämJ\x12\x1eN±Þ0=\x16j@׶`õ\x0eàÜ\x0fS¾GKqKN¢À¤x¼"5Ì,|&ÙÀS\x02\b‘)ÅUÁ Âê)°ˆ„\x1eÆis3.Ó*@áó—\x01±<ƒˆÕÊÔWÔÕÁ&Åd0Œ«\x01ª’àÁn¦.÷ãEW}×k茮½‚ïy›/‡+ÉšX/GG}œwÛØ„½+¥LÒ„€Ï\x17\x19œæûP³6ÒËóº§ÞfÎÒÐe/·\x1a!Ⱦjý\x05n\•S\x12Î4!^âH O)4iÃ\x15\x06\0œ‚3V\x03eTBwè.t”\x0e\x12[uÔ°\r\aNÞY1)•` \x06\x1eG|'6ÍS\x11 \x13Ó1Ñ‚»Í^[j\x01\x1c¶%ñtÌ”Rw¢KÍÒñêt9æzf%&\x19U×{­Í"´ÞÖ3Y`“ZÔö®èõøõœ}ûæW*¸&v¸Mû2‡Ú.\x06ܝӢ±Ê\x18&ÃØ–Ö¡\x19Â\x04\x0e\x12\x05J¶K§\ÎÛÏ—ê\x05D'íH…+üÅú“!\x7f]‘Y_ÂÔDµXTFBþ2±\x15',\x15rÝp\r¢ÁÁ±¡ÀàʪÁÁ•\ªÝVƒ*­ÃƒuZ\x1c\x187\f\r•Ã\x13\x18«^[h­R©bc\x16‘Sˆhl--,Z\x10¬\x15KF\x16™PQª¥L#f@°\x11nȱXDZŒO\x02ŠÇ\x04® Ôsb´Ä¶*§"\x15±
Ù4²URâ¬$–”’˜\x03\x15(2¬PL0\B­-\b,¶&Ò\x0e\x15\x13”áBeV«%¥Š)4À¥–\x1adZ\x1a¥d#Hi„á†ë.	*ʆÒá.\x15‰n¦Œ,di\fa•'\x05Ct4œ\x18U\rÔƒ"‰¶ÚSŠ–‘IªØ,)»#TÅ4£\x04²¥‰
ÔaX©2l\x11‰m_ÁEv\x04ì(¬¨ˆ¾Å\x15‰"“ÜQX¢(ü
+)\x14\x1fТ²’Šïv¬ñài³ÊÇ\x0e\rV›ã\fnã5pc·ºeiZÃl4ÞSL³l™—\x13zNg8嬵ª¸lÞU³Y9¹Ä¨\x1a^[$Pˆªd¸i\x11\x14å\0âTÀL\x1cLmq[\x19–™œ³8Ýk‰¬ÞìËš«FØÉšk27­åZo6­®&7\Í )°dK”\x03‰‘CˆN@d…\x10Š(5ZoŒ1»ŒÕÁŽ6Þé•¥k\r°ÓxZ±›²f\Mé9œã–²Öªá³y\x04Ä4EHâT\r\r’(DU2\4ˆŠr‚Óyµmq1µÅlfZfrÌãuÝÝó\x7f…4Ú}\x1ešŸ\x0e…TÓ…7[i³l}1Á‘³#ÿ\x14J^\x19*’öL\x12À`ʬUPõX)[²\x13a%†I’¢Å’ 1&J¡Le*¡„L¥\x17±eBÒŒŠF\x13)IlB²U¶Ö\x1c^Ó\r5k\x1cðÑ­\x193Ž\x06£ƒQ¶Ö\x1a·0ÓV±Ç\r\x1aÑ“ý…¯†Ô¹6ÖÔ¹UÉŒ’±d£%‰ÂªÁѮƙeÇ\r8àÓŽ\fÃ\x16X²¬1•†YefVTƒzŒa™\x1aL³,Ë\fÃ2òü)¢Ê±?
\x7f¢¤•Ôd’ò“¨e\x16\x06GDjb\x04ºI†¨5F’ëR•È\bí:Ë')Ñ^[\x15S¤i[Ö+,íÿfÚiÊ\x7f¹ÅV\x06\x01è^[ym©IX!Xj0ŠVU„JÁ‚š2‰’¦+uÁ¨ÚÈ8W\x1c3&7\x16¸VpÌœ\x06õ¤ÙÄp²\x0e\x15Ç\fɍů
Š=—žš4˜³Z:¼…Œ«•J^Õ`.Åa֝›zíVùLqÎJí	bêG\x12UaPè]\x1d\fZ,hé)KûÇÕüEº»Ú¥hJ¬¢}×uSÀ…d\x17‹ï^[«-c“òƩZ2h²\x03Xè‚çž’ó½î]GE\x0e±‹\x03\x059=R•u\v\x182/iD¿\0ºæ8Ç\x13)®Z´™¥³m.Y–œÌYrÝ›Zecy‹.ZÙ»3-eÅ…®ZjY¥³m.Y–œÌ1Ãlðek±‡\x11º×`q‰:FŒ\f\x06)10]û<C•¹ÐíZåÌ9]\x15\\x12»¸:¯š™hŪ\x15UÉ:EÃzŽö¨8ªï	sµ0t3yn˜6r­T•eY)ŒF\fL\0·\x06:ˆWÍTM"Y\x198U„ÁVU¥p%Êæ‹7Êã6šW*Ì[MóuÊÞ©›àâÍËQÀÌ<ÍMMÍ͏ƒ—IÇc1¶æög%´w£\x05TÉHwènkSr½VŽYªÃ[*&F+\x1d.Eà0e<Ò5P/*†Ò\rJCv¨UØJ¬šÃ1ðÒÛ*q£#sµµ¸Üâáf\x19Œkm-²§\x1a278]J\x13½Å–.ÔuE'…Í-\x1ar§DU®ëq­-.€Ýo9p^[·Y›mS …w7dq†¬p“ýŠÿxU{+ÿ‚\x7f­£ý¯úÏú&Ö\x18M´ZWJ¿\x18ÊjåôëŒÿ©ùM[ºßUÞ¿õü×eþ\aÿWí™]þ¹Ÿ²_…\x7fˆý‹¥öª‚¯Æ««þ\x0füWꝋ…ÿùÿ^[Ã\x18ÿƒ\x18VÇüƒgUÓ‡üZÜ©öÿWáRu]\x16–¡Vªc\x1aŠÁ—ª²ÞØÇyRX:1Wÿ\v°öX[pßv6÷a˱´º§\x02ô4½\x15\x13r’z¼^Õ¡Ò\x12ÕT=<?Þ^[¡ìbí\x1fŒÍ3\x16™­fkLf3\a‚òÿS”?àT94¶T4Ñѧw\a\x15q`#³åØâqHäô´¨è¦=Ë–‘Þ¼«£\f^ë\x0f„»2*Æ&\f®ŠÉÊ]OÉÉÞ®§/§áêûy=wc\x1fñ›j÷[¸Þ1»QÙ©{º^â\x15Þêتš\x1eX\x7f©ì	/·±|:ª\x1d¡õqW<c\x1eæ</Ý]ÖžõÛ–wu\x0eÌ\x0e§SAÿ;ªæðÊÐ…wR+³£\x1e_•ÅËBÿV“I”¿\fáƒêÃ0Ã\x17§µûx==+ºÇZe÷’µ«/\a«¡\x04ü/6­N¶?ÝWz¿‚è{^[aîáðù\x0f`Àð©e^ì«w—â~Câ•KËêþ\x03€îŸÇÃäò»Ý–—½\x19V×µ„ðï\x12ŽL\vo‹§v$+ÃÜíŒx„NÕKôèM+MJ©iw6ímècÓ<1ú\x1e¡4¾Ü¶£Â2DXÞ™æåîî1£Úu\x0fÈméá¥\x0fc»£ÝpüUÁ0=®¡Ë ÿ•uz«ÑŠ±ìü¼¯ èUO‘^[®ÌxeN\x04+òôðê!_.lRµxv~\x1f\x0f¡Òòá\x1e/—§C—Üëѝ™Íàè/‡Ofû³\x7f'j}\x060ʐpƏsû9|<¾ƒ½§ÓÛ	^ª•;ÃÙÔü\a‡!M:´Òü[²Ó´R^•Ã\r¶ÇÇ,ÔõeѦﳳ\x17uc\x1c“´96u\x7f‘£âÆ}ãÞÞf›cCœc\x1e¢E\x7fWt~\x1cUöÒ¸2\x0fƒš»¢K§lc'±ÿijðyÎ35þGz²\x10¸<c\x18åèx«a·[áí|¿{Ìôìët\x18»®çZ¥L»^÷³ËæpðÇpÿºáôÛ­©ì|\x1eoó~Âõ\x17`âJ/Ë»ÃÈl¹>œª÷"\x7f\x17Ë\x18å£MZhÔþ\x1f\x0f§\x0f\a½_—Z±nü<ËEÃîÜÝYjíiîÿ\rÜgn™XáÁêà’_qôú/{²aåZ&ž/\x12‰vQÈIb4Y
,1k3*諃£¬§‹Ü\x1az|rÆÝŽ\x1f\x0fûÏìᇚ¼½+ÕM/‡\x11ÐèÒÆ#”nt_\x06\x16ØÒÓ\x03¨{ÊkÃ;:#ñvv*%Ù\x7f•³ofª8wyªTû\x18”W±·\x05ÐzWU–%»?ÛF.ÇÑÝìì¿\x06›\x7f°?O¡Ðÿmöü?Êáàcઞjý†èÐÜ4!\XV+øû}>GéËô}Þ\x1c¸y‰G—’òÂ<¥ö\x1aGS›»jåøbÇèþÃà_Aåâª\x1d¦;½TƒOíîOš½êÊŒ™eà¬?e¦Ûl\x18Æ\x16Þí\a‡’Ò¡ô\x1e\f;\x0fšufc;0ñi±õWbhÁÆ߇wdÄòù_\x0eô¤¼˜Ç.\f4;¾\x1a»§7Æ1ŒXÇCJ=æ;±ê¦‹òÅù|OG–Ýá\x15Œ&çACK\x1d\x18tÓ:¼;,Ye§-#\x1d ‡íîŸn^\x1eÅTóV\x06é±—a—™ƒ/Ì1+Š½ìu²íY9t\x1a£ó`Æ\x19p5i‹wÛ\x1f5bQ_Qø¤lë=ï.Ýs3;Ý\x1cÛ•Ôû5taѧfÜM¼^\x06ž^[U\x15¦4â´Ð°?6Z¨iZ?\x11îú¼\x17n\x18ÓåûhêÛò\x0eG—/j*[~úè_n\x1a,»…U}›=_B\x15îû\x0eóô\x1d.MÝ—tÄüº	¶=ÞSv«"´.¯‹áæû\x1d'o\x19•Ü•í\x0e@÷tj¥¸˜÷t;<ºY¬Ö³‹ÝÝû~˜v]Ó\x02ñ%V
1’¤ûžs8®Î\x1c%‘ÙŒ~\f&šXi%ˆÃLcú˜\x1a†Æ\x18Òr÷Q¥G»†Ÿf\x15a’\x1eöš\ŸÑå\x1dXõ'‡ÍBbhRéø½\x19nÆ4i£@’Ñi(¬n¨®«€ôl¶5˜É;æGFêOŒÌq™5\x06\x062-1…‰±ÌNŒ\x18`c\f\x18±á¤Ò~\»«©¡ËÑ;Lv\x14¢i]	ùc\x0eaTîû\0=ˆÀ‹Ùîm¦“/&=Uº<šcɦ™!+¥¥)Õ’ƒ\x19*\x7fõ†0J^^[iø«Ãð\x13\x1eâŠá\x1e+Â÷\x19mKÞ\x15:\x14Á$ù*QÊ\x0e]!캏1ðÀX²¨¦,L,±†\x19K\x18
_ý•„Õ„°Ûß\x19Xܹ¼c\fTð*Ë’ïÜð›Uïw]Âë)̦](G	ÝŒX—-Q,NjÚÃ\x16UYL\x04<_ÜPž\x05\x13*Êq9u%åÕ\x1aÆ?ý‡Ãfƒf\x06ž5a9Æc1ݧ¤¢±"ø\x0fy’ð\x1a•I=Ô;¿gZ§—ÄÑNì1i—Û•1†R’Ȫ¾Ú„–Œ]\x1d\x16•ñŽŸèøuràÇ\x0eV\x11Ö®\a&¥0M¹iÛœÎ\x0e^[lÛlbpn­\x1e.\x19\x0fOs,22¬™TŸáhø¦•Cƒ\x1f«V¨²°ÊPÊ,a\x7fQ)Xô\a¸•Åº‚¼Û½À­Žéy­\x15+–\x0e“,Æ0F\v)MŒ#@Âtv);2 \x7fl‹\x012\x06‘–1\x18jª\f¡\rtÖ¾uÆ3áÃJÊcºSS@Í\x03ƒÀ£È˜àÑ ,¨ˆ¡š˜Ý*Õ  å Ü\x1dmœGIR\\x189£‡\x04àêÒràs9œ9«ƒ—.m²tHò•‰\fXÅ”œ«š;¶àQX°Ê˜¬e¦«š*\Ôåw«G\x191c
\x15‰ôV„+f\x1c¥öT|0cµÜ»¢“,bå´JúMÙ\SL^Q!Â_édU.—ì\x1fÓàãÒŒ°ˆÓ$Æ-\x1ahˆÓ\x05Q¦5bf\x1abjÄÉ…Œ4ÃLZ24нš)%¦Ì2\x15\x15”T¼+Åfc,°Æ\x15—öµ@¾-Ÿ¦=Šº5W+\x15
áM4€´Â’Z0)ˆdŸË\f±ì¼<U\x15µÝ÷‹^[^®*ò’éÕˆú¥\x15™Œc\fDW\v hB¾ÌS±Pab…l–¦\x0fbWôÓݺ¨_\x15Ò§²÷,<ælmÜ•\x1eÑWj¿`÷tpb~˜\x7fWÐÑÀËNÛtp¦m¶Þ•\x16êa¨%¸õ$ÓI‰\x18.Ø”›²âµ¼Ì݃TÆ©ì;Û\x1cŽ†W€Øx\x0fw`÷c‡JU.¶-\x13OccMÖ®Œ4ÉÝá¥]㱫\x1cØ°ÒÐp^[\x1c:™Œ†\r¦‘Ë*a±©áµwmiï5B:<†,KáÖ÷6\x1d†\É\+â¬K\x12ªa…UX\x18!\W\bá¥\x0e\x04+j¡_LzÓ4¾\x1c,¼\x0e„!º®LªcŠþŸæáø\\x04+FÝf*OJ'fàâWgA§‰T“ʹ\x0fV*©Í+f*	Íüi¦1•Œ\f|±O¢´M\x17ÝŒ¸Z¤mÔ~,yQAê˜u\x0f/'\x15aÁô§i4=GqâÝSV	ýMÙ\x1a®4ÚqT÷u\f\x06êèŽc‘,5N_\x15¶K)Á(Ýn඲Á—c‘»rªZ¹eM\x0f»W\x17FG,¹aôÇwwk«Ã˜ÕÞŸ²ÝâÚêèx”KsNç\rÝUÃN^\x0eÕ¹Þ»;Ü\x0e§…åqpàÇ\x17W\x05ºËÃnæ1ŽXòît\x0e‚,èG\aSDLD<»Z؇è\x11k\âÉ[ž¯\x11(pùK–p”å·Our=Êæõìœeï†›­3’úÍ㪬Obä愍¬åW\x17Æë­Õñª]\x1dywS]´¨é®‰!ƒ\x10aë\x02 "6^[˜àê½ÖŽÎVZ½’ÕŠzU¦×¡æ­‚–’{8«€F⎮[\fVG¸ªU\rÞ^[t^Â\x15غ²-ºW'\x1aÌ®\v½ŽÃ†âQà\vƒ^[~Ô6Úó]ÝY'g‡BìÆ1c†<\x12¶éco\x06\x1c±¥¶=9«°érÛ\x03\x1d\x03gdëW\x06Ý\x11%”¤´X/Lc\x0e³Ã¥'Ge`{®¦Ž*àò!X\x1e‹„áìGDrî]&\x1e\x03¢¡è­J’öwGQµËŠ·W\x0e'£e•ƒ\fŽcƒGéhèê!\\bWWtu»»µI\x0eÎ\x06®äwv¯
^[LY\x18ÌeF2WXòȱ”he\x12ʱؚ9—k&_â¬\v^[£àì©ðæÿ@âw4R+\vûœ‹µ]]ž\aÁì\x1e\x05Ç
ŸcT–…iOAh­\b¶“ˆ0îx\x11 àaX¥\x06I\x15[\´öbñ\x15b¾ã%nÀ\x17ÑaP—«ŽD+ý\x1c^^[\x14+݇Ic'\x01¡ý"Ô%Ø?Äá{¸=Ä+^[rþ1œ³L’šjpw\x05”öš)\x16Ñ\x13
«Ð;×Vãd]+\x1f\r->\x1dXA]Ë\x15Eb]#BÐâ(峸éØÆ~Š©¥¥ìUMN.\a#ÐÇB:½:έ\fe\x17†<\x19T'6Qc
G2á2'hôUOËØBº\x04+\x18ÃÃï9f¦óg-½Ú˜`MÊ\x15‘Âr÷c‡\f2p‘bmó\x14w\x1eD+ñ*Kµ_+­£\f1aŠŽÎFÆ/„TjA‰}%„•i‰•1‘=Ìi’‘c\x13\f\x04iŒe}³\x18z\x14Vïsjþî‰AôGIÕ>\x18¬kLŒ\fL\x7f úC\x06\x17.\x14ì]E<=Fر”ÈÃ$c"Ë\x19e\x18c\v\x11…ŒS\x18†Y\f¦\x17#⸍U`…má
–:ÌléVÛwˆú
o¾a}\x05É/ðUOÐáHW‰“š#pªdöpÃ&F\x1a\rB½˜Ùñ\x14.)T¿J\x1eštR¶ÊS+†N
/£›ƒ†Í…‹“ ª›N^\x1aw,u\f–¬YY&,0²L²Úʪ\x01L0‰±¥/Ë\x0eµ^[\x14V’\x15…~MF¡\x13!\x13àQYK,ŒbË\x056,%F‘I‘eÚÔ¹
Ê“\x18É1‹(RÊË\x06\x06åIhj¿ŒCÎxf–ž_á\:\x15\x06(aU0öOq
Å\x02èOOÞvÌŶ[Æ`¢·7i¥\x02¸&œÛhbþ-4ÄðUM“‡\aGEՏ•¶îŠìÔ\r1\x18Ë\x18YL1”ÅeŒ˜À©dÓI4‰,‰Gàòz©\x1dŽ$B¹.®\x1c¬²K)‘`Ã\x18F1\fe]SN®‚¼]\vÍŒ”a‚‰;)ÛpÆ]W•áWè‰Þ‡ò2*²ÐÄÌÌÆ?iEm»\rÚ\x18ʉ4M.…\vòÑR[\v°ôuzsTŽ±\x1f\x18Æ\x1a%Ôˆp¥F#µÊêÜY+Vë­°Ø*º\r·KDœÐ¥µÂ¡Z±åó>Ü\x06é\x1e¬”4\x18PÆ\au”Žæ\aÛÞö‚Œm1Ã	Z²\r\x1dÍ\x0e(©\x7f,aû\x10¬aB¿ok—å§z½
©úl• …dò\x0fô`x*¦'ø>O”þØp*§åGgƒËôûhæ¯.8¿¡Ø¦1X1i¡ò§™;8Gíöh׶\x1akLämÂi¦V“'”ìûZ¿AµOïlx»©‡ápböjO\x1fv1¶Ÿ‘· ÛO¥<‡Z~1c=Ë/5\x14¿\x051ŠÊ‚±.ÄmUCEÃ\x11üe\x02Û,6°>ŸPq5T©¦ï7\x13*É‹-\x18Ý@äå¡q2·\x15îÝ
^ÈCî«\x16U„¿X¤&–\x121a2\x19Iº»9\x10I»,²²Ëâ{Ž·"µ>ç ë>\x1d-\fXc\x1a«^[Oày>"ú\x0fÞ,dMŠ$ù¹_W-Úne¨Ó1”Ó\x1fÆšÚÉ2q
§\x15Tv9\x10¬¢+-M\x11\x15©1Ë—U\x19?ÅOºª“/›’ê®nEÀ\x1d\x19\r\x17Íí\x18û £Ù	\x1f:Ê|Ev…\›¡\x1a^[L·lÒcWv“k\rÙ\x1aµpš^[Xjhîų +s,¡¶–ìaŒ26U–¿mZÞ£Y3\x1d\x18Æ5•˜ÍëZÕ¦\f·B–‹
iѲÐÂmÐÚÐn°ÔmŤ¸«\x10’åÊÓbЍ\x13EHÑBjdŸhÜ\x112ËuêBdx\"K&›\x14VÅ%¸¤°ÀþØlÇ3\x1c1*·T&\x1a²v%e]Ï•X?ÁŒbö\bV\x17—6Ÿ¾[æã3™¬ÌmÏVpäQ\9[j\x15i¹XÒÑl©-U§ÉÑÍË„á³EC™…ÄÁ
ÛÒNTÕ_(9\x17›µN®h৲º:\x17ÛU ò0b¨2Æ+\x11šƒ\x19o-6oy““f¬JÑp´ü“†Û1pÕ[2F2\x1aT6ÕƘø’í*Ÿ\f&0=Þ\x1d›ŸÒû÷ütm¶Ú{ª©èôǫýá`…|\x1e­1ŽJ©·\x0fW‡³M>dRÑŒYJ¥‚Û\x18cöÓL4Êi;(ÛÒ½N祌c\x18b²*V\r´ú\x1dŠ‡\x0e,eŽ$¢<+ÓÓ½]Q§ÍH¦Ófž\x14&ÇC\x1fÙ³­ø\x1aU\fpÓR¤snõpáÄpÄ$ž5.Yc\x18\x12SrÛ™"‰\x06(\x06\rM\x03\x1d¥(‘X(¬¡Ôå§ÉÅàB½:¹W\x01‡§'ª½”:ªà'½!^á\x17 þ?\x03¼\aê¸h42þŸ¦%¨“Ӑiø²rc—°r^[¸\x1d\x1dœ\x1c¸”å²™0>\x05ñ\aòêþ×ÜK­YR&Ö\x06\x18×;Þ³33[i=í4â¬K\x11%Á¢\x1a§V\x18ì£ø[.e“‡µÔǼžíªO•ø~\x1f·ñôŠ\x7fwð÷$§Ù@Åy/²\x1fKÍ?5ꢍ\x1dEz¾WÅ÷Êâét\x02¼.ÐàòÆ\x14S\a‘ˆÓð!Zjœ…\x16†*\x13“Øéa2r$;¿¶B+¢\x060W¥Aw_\x03\x15ñWÎéW ªt«Cª\x10èWºµV2FŒª*ÓE¢ªc\x18Æ4ÇöÀlÆ֍4Ò¡¤Ý£L&5½k\x1aÖšz)')\fc¦¤‘’1#
‚	„(\x10„\´_\x166‡,82Û\x06Úœ6á¼Ìc»)¶Î^î\x13–2¿-íB\x1aÆ2
\x1dªèÇ{”*¹\x0e\x02+’°‚j1jÒÔ6Ôï[ªå10ÝY1qI\x197\x06Õ\v\aË•N2c\x15‰w{.Ò¤ºE\x1fÙô…K‚ÁÔUN¢fxÆXÓ\x18(¬CÂB´ZSfà£(©rÝKy™I+\0É"»N\º+\x14àÈÀm \x15Ñѱ$º9+Œf\x16\x06\x10†\x17vOóòÆÇ{ËÔüT±\x16M\x17'7!
ËÉ\x18\x16\x1e\v\x14L2£nLf2ËÕi\x02ÃG\x05«h\x17áÅÃlG\x16­2æ5@´?\bÓÐ’\UÀ]\x18âï:­&\x0fÅ¡Y_ÓU*šY1¦ªÒ°»tg^[ã5†˜ì(¬´ÛC\x18€ÆJÅQYc\x18úªTƘÛ\x16¢¶Ðb\x18,2TÊ•^dz‹Âý´\x18T+
ÝD§GÚZ”‰òbÁ”ÄÄ¢vqB—ò\x1f;o•\rT¨ÊT«\x13ï\x1ež\0/\x0f\x06Þ"EvŸÕ/‚v“ðÕJ»U“QØ\x13‘æÙ°áÈ1\x18êŽ\x14Šö© òʴц\x18é\x16£FìLaþRÛ\x06&]˜š6*§šQX\\x18$—(c\f‘]ª(å/\x14\x0e÷ΫÚàõZ\x1e†\x177S\x1e31˜¿N\x02]Oc¦.Z̳íU\x15ý¶ì÷«±Á·2ú)\x17ºsWƒíìdu˜_³ÑµblB¶þžÎ÷Í\bÙöŽ¯Ûñ\x04Z\x0ft¢{ÃOv\x18ô2ýCbŸÊ{Õ„ù«\x14e4Á¨­2iƒR–«E)jÕÚÛpÓ*Z\x16\f2Ó ü6՝ùÌÆÜðž^üfÝ7–r͇Y¥IÂÙu8Q%ìnü\x18Æ.‡6ÙVN\x1a*¥Á1\x19F\r¸‹m\x0e.\x06Œ©låù“»›%–C,²ÆI‘‹,°¬c\x19™f3&Xva"{±VU»JÆšb`²Å¹\x10Õ¹\x10ÝE,„Å*Y\x18ûcJÁ‰XDXÊÁŒ\x04dùÌ֬ʸV+,\f˜d©\x18Ƈ,¶\x16Å\x15Õ w;špDú“Áþ'árøe\x7foÈ…wG	\x16=œ¼,^ªŠô¯Mž‰æ°Ž°ŠÄŸ\x02\x15ú¹‹»\x11Œ“^[\x1c•VÜ1jí.jn2°Æ\f±…ˆâŠÐCP±‹\x18‡—–¥4è\r.\x06+\f`Ç\x16\8¯+•ÅQ/Ó÷BLbÅàÃòÔn]•\x05—@¤å‘¥"²Ë\x18Æ™Q™Îµ¬iüj©S¬1D®Ôþ\x1f–%b|4ÔO\v\x18åæÓÜß\x06m‰ÂÓ&†î\ageݧ—%Të(–$+Øb!Z±ñcL7½o\x1a\x12g\x13\v†Môßmµ­Y£}¦ÕfVc,ÔÉ‹B\x15ƒnæ‚UÞá©Ë$ÈÄÂÆYqcOà©.êì§À¢½IscªEŽ
Èy\v\x17E‡‚°ÇwÃ\x06˜¥´ý0YS\x1c¦š«cÚ­\x1cQÑÑŽãep¼Ê\x10ôÆYJ¥†QRɇØ;$µ8n°r1ÞÊ…{„+\x05JøÌÇ
†&X°´äþ=UÌseJŒG—ºº7e8Q©‰ƒ\x03«\x03à™Sý\x18ró?.íRdQÞ®^\x0f¢N¢¥òþªªNâò]\x0f\v›Àùpð^æ¥À…l¶û«»­Ì©,žÏEj®è\x7f\x1e•Éà蟖ƒ\x17QO\x04ØÄ`cÃØ,W•UÀnSiÂÒê\x18µeWÏLÍ1p\x18Z¸ªòGd%vU\x0e^âE¶:i¬Ì5™˜\bÄ mP\r?w«j”¸U”hÃ\f\rØš2­\x18ia‡&©4±‚1Ë\x188pÓlYJ\x16&#–Ü\x17íÃG/ð\fVÓ©\x01\x04\aøùóÇJºZISãi™)šMCBX…œk3†û0Q^¦—F5c\x18÷bœW»M4Âû«O.\x01µ[¹pÓ€ö\x0eiº`ð÷\x1f!ÊîùÚ¼"Ëçvªò¤Ž• þœ¸OFà†é~^ô þ1N·.\x1aLL\x19VÒ1(¬²\r\x16LÌÖšÖfòU¡-<\x03Ùúiú}ªÕ(Ê°\x11Ð{4щFC	Œ-±:\bW±cêí÷™ù·™vêc\f4Á¦,2eŒcéîÒÝNÁO\x16\x1fF\x115j42À´pTáXÄa‡¦51/ú
+\x17\x05?LTü\x1c–4pÇ\x16\x14U†Og÷\x14—\x15$´Æ†ŒiÐÆ+\x18ÆDÁæcO&\vOÅKKF\x18c³GÐ'@é\x17Ú\x7fg8au0«\x14c’\x1eE)taŒ\x1a¥¦Xi1«M\x1f–õ¦-\x18XN¦1•©2Ã\agÈ6n6iÖ}1ÿQEcƒ\x1cµ\r40°c\x16!‰û]\x05\x12i³Ë\x19-TZ\x14\x01YVK/Šµ\x1da´´a—cDÕŒŽï{uqeû«$C•øb”\x19a4™B\x18»½¥\x12ÃõEK\x03û\fj%,m§µ¨DÛKHÕÃvÚ„VÜ,8}6ŶÊÓ\x03\f\fe*§\x17&ØÓl™	.\x1fN_\x0e\v›)(Û“\x04@†\x0e\x06`‰$e@( \x18#UwàŠÆ”©ª®—îÅé—Y!V‚ÅùI#áש{MO\x14õ9ÖPX6”7\x0e¸e>Ib\x12\x12Kš™[ßN\x1d,\íß\ÖkX÷*§öÓÙÄè™(,¥Úå{8\x05qÝÓXÌÍf³Zµ™˜ÉÝŽk¢âó\x1cœ×\x02\x15¿«mW°t»št\ÕÍÄP­\x13a;\x15Sb\x15«˜U8\x0e\f1Ë£c˜‘XàèaØ:=œ©ÁvŠ\x17XlݲìY6Sk\x03²Ë“\x1dfœ\x15S³Šµ=TÚæznº6G'CÔi\x1a#¸É‰EjÕ[q\x1a·aË\x15µÜ;œR~\x14;»:½"ô÷‘}ÈÉ\x0fòc\x1fº\x14½¨JåÔsFâÁÑ©MRµ™™~š4Ê°YBVM©ÉÙòä«\x16Udvc\x19pÕÀh³Òn\f\r\b\x04u\x18á\x06áv‘K*¦b•>1ºÕ€\x06ÌjÆŽ[^[cLh6¬KF\x14Ƙc	ÐmŒbÙn\b4\x10®¯¦„+/ä¼²ÊdÁçYeÊ\x0eò(ÕìÉ^\x15eW¥cðÅØÊ}ªQÔB±UNäLw½6£Ù÷r“a•=‚\x18*ñ<¦\x1dØÄ*]ËÙlÆBƒ\x1f\x17j\x05\x15ä÷îÆ›wu\x10¯	xWÄ¢^,»1ÂI/º¯Qá62@eÞË2Ë%â
XÊ\x17\x12Ò¯\f;·\x1c·z¡KG›HRÔ=U*cÙ8\x18c1Õ††˜e†‡Týæ`èýŽ:4b¯\f>Âö!:8p„®§™T“˨2¡þQ_訷HV\x0fâèÒœ/Íù\x0eî\x15·²ð¡ù\x0f¹üUØ<\x03ò\fvB«áDha•B·\x1f/ê¶Z¤© Æ–\x16"e\x10®\x11îµWæÉ'†–š1«\x10bÅ\±µI¦0šcÕ\6Úü\x13³WÃò.¬K»„…~B/´:I\bêÊ\x01p\x19ESQBÊ)X0éVƒÍ\L\v\x01âý*Ç•4W,0c\x18ÅJ0Çáà76[1\x1a\x1dW†*v°‚â\x1c\x17‘ÁÞ§$…jÓ
Ã\f`-5Evn§èBºŒç\x18ð§è¨p›yªtLv\x10­XÅ‘•‹$†(]"}U·fêqu'g'\x14Êþ˜±È#V\x1aii¦‹F%j•XÁóT©ãôÄW¼8´\fz´¥S^[µTæw\x1e'èÉ:$íGÛG5c¡ËNÛ,\x1c+L4Òjª©†`I%Š"\x06P’mc‰T$71 ¥TöÓyo[Íc7¬Ó@ŽÆ«­ô0ùmËì4ÐÁµþËt\x01åù¾ß‘Ľ¥$¾×y<?."C©_…Q]*>ÒâÏùŠ
É2šÌœ:s \v¨òü\x03À‚\x03\x13ÿˆ\x10\x102\x05ÿÿÿƒ\0¬÷¡ô
 \0\x14\0\x14\x12(HR@ªU\0U(P\x01 \x05\b€  Q!€\x1ahÐiˆ\0\0\x06@\x18\x01¦\x06˜€\0\0d\x01€\x1ahÐiˆ\0\0\x06@\x15ùU\0\0È\0\x01¦\x18&©!4\x11©“BjŸ©¨d6¦'Š\fJˆ!©¤z&A\r\r\0\x03ÔÐp•EWÂ'ñ¯Ú\x13ÏòDþ0›A\x03‰\bw`(¢Š(¢Š(¢Š)˜Rµ	ý6Ú\x13÷¡?±&ÈŸý	û+õ”b&ÔN(ê'hOí	ÿp\x116Dî‰Ê'DOëDÖè›Q;BtDýèœÑ5\x14¸)vCÔ”´”¿ÙKˆD_®
æ‰Ì'¼'Š¼Wí^§\x10Ñ;Bx®Q8®á5O\bZDޝa5	í	ޭԮМ½]š.°œBi¥G\x10a6”m	â\x13o0›Âz¢aèI’±Ý.Ò­™WêÊÙµcŠRÐ\x1d×Q°hbFyª^\aUÚÚé|=^[¿÷Ž›yßkvzoé¾®ŒpÚtdÙÑ»£\x1c8¸¶·´¶³é{ê„EñP|‹ðDÂI~„˜”ÄM"\x7fDM"~j&è™TL¢n‰”Mè›Q4¢eDÚDÝ\x13j&‘7DÄM¤L¢mR7„ÄJÚ\x13 —TLªKhLªŽ!2\x13!7×\x19¨Må\x1a¨+B2¬­Õ\x1añ¨L„ÈLRZ„ÙJÒ–ò¬Ô&ПDNª…+Õ\x13\x10ªú"b‚yDÉ*Ÿ„LIJü"e\x14®G^ÊÓ\x19%ݦ̩³ª\x17ò¡S…DÄL¢dId&"•f!2\x13*T¶¦‰úR—Èû’'äeRÒÑBtÅ*ÓËX¥ú\x14°\x14¿QK’¢fFôª[ä'¡9DÑ\x13²&*•l\r¡4¢t„ÈMEKð‰úI5	‰%»\x10\x1c:)\x13ÇÖ\x13Ì&ÀÞ™		<"b&
–\x04ñ	„4¥\x7fP˜ñ·y)k!9Q;¢w„Ô&•\x19	Ú\x13!7„ʉý\x11?©Sù½/KÒô¼ïxE\x7f\x05-ËCæRÁGç	þpŸä‰Ä'ñ‘8¦"~ˆŸ£ùÂm	¨Má?\x13*¿¼'ë	Á\x13ªe\x13ýÑ?GŠì„Þ\x13Åz¢zUòDéJ—¬\x05u„ýÙ	÷DýQ=(žÔL¢tˆ,‘<;Q;B\x7fÕDÕ\x13÷Då\x13z^a=¡6„ø„Ê'š&êW…\x13ÂTºŠ—Ή»²èõ¡=(Ÿ>𞈞(š¢j\x13Œ¯\bŸJ¾UÀ&sá\x13„OˆM‘?hM"t¢{Bt¢x¥K(›\x11<ÈŸÚ\x13d-Ñ1\x13zÈOXNК„î*6\x14»á^q­Ð¥Ì¥µBjRqB~U}(‘;Q;"uDÊ&¡6í\Q=¨¨ïDó	Ì'jGhNÕÓÇzÆUÝ\x13ˆN•ùUËò|Ý¡;Âk²&ôNQ:¢p‰¤O²&ÈœVQ•elvŒ*^¨!¦q`ªÉÐÈÅíTµ)b#ŠÔÕRìM\r‰MÉ4ø¢t¢zå\x15¥=‰2
é	µ\x13û²‰ö`¢u®”M*?Z\x13\x11>©*MQ2›S—TL\x10d•æN\x10\x17#EKÊ©NÅF„OJ\x15]Ñ5\x14}¤Na9«Ö"lê‰ót‘:×"¥ËxO\x10šŠŸ”'ˆMê'ïJ—\bœÔå\x13Ò\x13Ö‰Ü\x13šKÖ‘8ˆØqìT½ª–\x15.ø!ÍRìaRÿ%L\x14º*X\x0f\x15\x13ðHš¡=á2’[)Kë	õ„øDÒ\x13hOul®¨\x11:BqÖ‰ª©æ‰Ä'\x0f)\x0e!>u\x13˜…¦2„ÌDÉKSY\x18ª&Æ%.\r¤„³\x11Ú‰â\x13^[Q2‰¼Eªšr\x13¥i\x13q\x15²'Š‰§\x0fb¥ê”·7)hRÜ¥º¥’kƒ)Kr–%V\r\a®ÑRà„Ù#Ê'Z'u+(Mоðža=d¥Õ\x13 '
¥]ԍ9Dô”O¥\x13š‰ê‰µBt¡<ê^Ìÿ\bžò'º'â\x13tMH›Bw„ú)^^["mDÞ‰Õ\v¢'0á8l‰Å\x13!Z*^r–‘W3\x03\x06\rN¥.\b]a>îiUÄ&"\x7f\x04LWø¡yX)|-e-ÎX…[…\x0e‘\x1eÆŠ'Ö\x13(Ÿ•*Y	óTb&ï¡\x13P™	ïPòû(N‹ ÜÝ)x\x15,û\x05KÅRò”»\x02|¡2J]Q5	Í4Ê'ÖRóà\x1dG!U0bRÀÞ)x!4‰Áw„óJ—t,ªCÌ&\x04ì*ü¡5	î¥}XÕT—J\x13½rDÚ\x13ª&Bd&Bd&TMUb•ˆ_z^8Dì	òj‰¼&Bd'œŠUÊQ8îQ:HœÂ|á=Q5	Ò‰ì¨Æ$6‚Y	Ë(Ÿ4R™DÄ%6¬¢s^(O‡Â\x16Èžô©z×Í:¼aØŁ‹¾"ÞRÔÐ¥‹²à©e	ÙUVQ1Ú\x13\x15Ì'¾á9\a‚„Á!‰K2–—2¥Ò\x13j‰õDïW—j¬}¡>°ŸXLe	çw™)iäU}\x11:ÔLªY=Š–\x06VL˜\x19Y\x18°d‰¦V%ªµM%a¬c)Ò\x13JµBe\x19‰\x1a„Ê\x13„\x0f0™	º&¡=BnÚ\x13éω\x13í^Q7„ÄO´&‘5	ïKB—t`„e,(O5Qˆ˜X*\Âeo	òz½(O5ò®ò&B`‰¤OA\x13¬&ªæµ	é	ª¯ÍíƶÓM6u„Þª1\x13!=T¯’w¡Uçµ	”O0™Q8¢j¨í	É\x13jû"fˆ¡5"uDìÝDô„êÞDé	¥)|«–ЛE\x1eðžýa>hž±%ã)*èÄM\x17®5ü\x1a/rRï^"-”§('­4‰´&¨›v„â„⺢e\x13Š\x13¤&’Ž\x1aŠ­åK‚–¥K¼ðC
±t\x1a›)\Ɔð\x0e¥KYKD¥Á¹QïXÝ\x13!>!>P˜‘d'Â'z‰‚&ø ½2\x13A>ª'Š”¾\x11:BqU\x1d]‚{"v„ûå\x13U\x13¸‘sÊ'µU\x1dQ5õ„ÄMÑ;"eB¼¢r‰õ"l‰é	í	≼&èžÏ…v\x15,¯„LId&J[×f¡<ê„Ër&Èšä×\x10š„ø„Ô”²\x13¼&…K\x112¢d'ÙÚ\x13šJOž \x03Ä·”¹ª\‰Y<ª-HZ¥\x1c¡`©oPéV¡=¡6„Ô&¡2„ùR\x1e>\x1dªÈMW—dMªRå\x13xNjá\x13(ŸZÑ<+¥B}*\x1c\04TºJYT»Œh0\x15Î
ÒRÚP{’'Œ¥Ü©u
àRæRÔ¥‚–	âm)d¥ÐTºÑ1”Na6„ðDÞ\x13h\x17\x15	’&)K„/„O•DÉ\x13(ž”MHœ¢n*^ôO¼'0ŸxOTOHOjÞ­U\x1a„Öµi¦¾é^$O0˜‰¼&ìL¬Hú{PŸá\x13¡T÷¬}a:BrîÊï*Ïœ&ÔMË\x05-Ê–:Œ\x03KÛ)l2·°‰™	”&d'ˆOhO4Oµ\x13P›Bj\x13!;2„ÓvÕ[ã*ÈL¦BvÖf2cŠ&"m	Å\x13hM¨›\x02qDÕ\x13hMºÖÊ'ѐMá43)r,™\x1cŠ[ß\bŽ¢—uHŸ(NµF«\v\x14½1ŒVQ˜ÅR­;¢s	ÑJ2„âœU”î*Ý\x13dNê&\adæ‰Þ"â\x13*e\x13\x1d$,éBt*VîQ:»ÂsB}èž\x1aDÈN\x04\›H™\Ô¥Õ\x13´¥Ôu!9ª]ê–é\x13AKy\x7f¥?	÷R8R¼Ñ=+Ÿá"püD_ˆO”U}á2‘zBvDü{×z\x13Þ)WJ&Bu„ÈMÊY)ir!0)xžD\x1aª\ŠY³)m*mµCÅRì3 \v!=\x11:5	µ	é	Ê$¯(T¥ïDÈ\x17„ð‰ÿâîH§
\x12\x18(3à

[RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Tue, 1 June 2004 07:56:16 +0200, Jörn Engel wrote:
> 
> So effectively, it comes down to the recursive paths.  Unless someone
> comes up with a semantical parser that can figure out the maximum
> number of iterations, we have to look at them manually.

Linus, Andrew, would you accept patches like the one below?  With such
information and assuming that the comments will get maintained, it's
relatively simple to unroll recursions and measure stack comsumption
more accurately.

Jörn

-- 
ticks = jiffies;
while (ticks == jiffies);
ticks = jiffies;
-- /usr/src/linux/init/main.c

Add recursion markers to teach automated test tools how bad documented
recursions really are.  Currently, there is only a single such too that
can use the information and there is always the danger of documentation
and reality getting out of sync.  But until there's a better tool...

Currently, this patch also has a few cleanup bits included.  The cleanups
were helpful to figure out the depth of some recursions and could be
useful on their own.  If not, they are easily removed.

 arch/i386/kernel/apm.c      |    4 ++
 drivers/char/random.c       |    6 ++++
 drivers/ide/ide-tape.c      |   33 +++++++++++++-----------
 drivers/ide/ide-timing.h    |   60 ++++++++++++++++++--------------------------
 drivers/isdn/i4l/isdn_tty.c |    5 +++
 drivers/isdn/icn/icn.c      |    5 +++
 fs/block_dev.c              |    5 +++
 fs/quota_v2.c               |   43 +++++++++++++++++++------------
 kernel/signal.c             |    7 +++++
 kernel/sysctl.c             |   10 +++++++
 10 files changed, 113 insertions(+), 65 deletions(-)


--- linux-2.6.6stack/arch/i386/kernel/apm.c~recursion	2004-05-10 18:10:06.000000000 +0200
+++ linux-2.6.6stack/arch/i386/kernel/apm.c	2004-05-30 18:24:54.000000000 +0200
@@ -1058,6 +1058,10 @@
  *	monitor powerdown for us.
  */
  
+/**
+ * RECURSION:	2
+ * STEP:	apm_console_blank
+ */
 static int apm_console_blank(int blank)
 {
 	int	error;
--- linux-2.6.6stack/kernel/sysctl.c~recursion	2004-05-30 17:51:03.000000000 +0200
+++ linux-2.6.6stack/kernel/sysctl.c	2004-05-30 17:52:25.000000000 +0200
@@ -1188,6 +1188,11 @@
 #ifdef CONFIG_PROC_FS
 
 /* Scan the sysctl entries in table and add them all into /proc */
+
+/**
+ * RECURSION:	100
+ * STEP:	register_proc_table
+ */
 static void register_proc_table(ctl_table * table, struct proc_dir_entry *root)
 {
 	struct proc_dir_entry *de;
@@ -1237,6 +1242,11 @@
 /*
  * Unregister a /proc sysctl table and any subdirectories.
  */
+
+/**
+ * RECURSION:	100
+ * STEP:	unregister_proc_table
+ */
 static void unregister_proc_table(ctl_table * table, struct proc_dir_entry *root)
 {
 	struct proc_dir_entry *de;
--- linux-2.6.6stack/kernel/signal.c~recursion	2004-05-10 18:10:38.000000000 +0200
+++ linux-2.6.6stack/kernel/signal.c	2004-05-30 18:24:38.000000000 +0200
@@ -626,6 +626,13 @@
  * actual continuing for SIGCONT, but not the actual stopping for stop
  * signals.  The process stop is done as a signal action for SIG_DFL.
  */
+
+/**
+ * RECURSION:	2
+ * STEP:	handle_stop_signal
+ * STEP:	do_notify_parent_cldstop
+ * STEP:	__group_send_sig_info
+ */
 static void handle_stop_signal(int sig, struct task_struct *p)
 {
 	struct task_struct *t;
--- linux-2.6.6stack/fs/block_dev.c~recursion	2004-05-10 18:10:30.000000000 +0200
+++ linux-2.6.6stack/fs/block_dev.c	2004-05-31 17:20:53.000000000 +0200
@@ -547,6 +547,11 @@
 }
 EXPORT_SYMBOL(bd_set_size);
 
+/**
+ * RECURSION:	2
+ * STEP:	do_open
+ * STEP:	blkdev_get
+ */
 static int do_open(struct block_device *bdev, struct file *file)
 {
 	struct module *owner = NULL;
--- linux-2.6.6stack/fs/quota_v2.c~recursion	2004-05-10 18:10:32.000000000 +0200
+++ linux-2.6.6stack/fs/quota_v2.c	2004-05-30 18:36:23.000000000 +0200
@@ -352,6 +352,12 @@
 }
 
 /* Insert reference to structure into the trie */
+
+/**
+ * Recursion count equals V2_DQTREEDEPTH, keep both in sync
+ * RECURSION:	4
+ * STEP:	do_insert_tree
+ */
 static int do_insert_tree(struct dquot *dquot, uint *treeblk, int depth)
 {
 	struct file *filp = sb_dqopt(dquot->dq_sb)->files[dquot->dq_type];
@@ -369,12 +375,9 @@
 		*treeblk = ret;
 		memset(buf, 0, V2_DQBLKSIZE);
 		newact = 1;
-	}
-	else {
-		if ((ret = read_blk(filp, *treeblk, buf)) < 0) {
-			printk(KERN_ERR "VFS: Can't read tree quota block %u.\n", *treeblk);
-			goto out_buf;
-		}
+	} else if ((ret = read_blk(filp, *treeblk, buf)) < 0) {
+		printk(KERN_ERR "VFS: Can't read tree quota block %u.\n", *treeblk);
+		goto out_buf;
 	}
 	ref = (u32 *)buf;
 	newblk = le32_to_cpu(ref[GETIDINDEX(dquot->dq_id, depth)]);
@@ -389,14 +392,12 @@
 		}
 #endif
 		newblk = find_free_dqentry(dquot, &ret);
-	}
-	else
+	} else
 		ret = do_insert_tree(dquot, &newblk, depth+1);
 	if (newson && ret >= 0) {
 		ref[GETIDINDEX(dquot->dq_id, depth)] = cpu_to_le32(newblk);
 		ret = write_blk(filp, *treeblk, buf);
-	}
-	else if (newact && ret < 0)
+	} else if (newact && ret < 0)
 		put_free_dqblk(filp, dquot->dq_type, buf, *treeblk);
 out_buf:
 	freedqbuf(buf);
@@ -498,6 +499,12 @@
 }
 
 /* Remove reference to dquot from tree */
+
+/**
+ * Recursion count equals V2_DQTREEDEPTH, keep both in sync
+ * RECURSION:	4
+ * STEP:	remove_tree
+ */
 static int remove_tree(struct dquot *dquot, uint *blk, int depth)
 {
 	struct file *filp = sb_dqopt(dquot->dq_sb)->files[dquot->dq_type];
@@ -516,19 +523,17 @@
 	if (depth == V2_DQTREEDEPTH-1) {
 		ret = free_dqentry(dquot, newblk);
 		newblk = 0;
-	}
-	else
+	} else
 		ret = remove_tree(dquot, &newblk, depth+1);
 	if (ret >= 0 && !newblk) {
 		int i;
 		ref[GETIDINDEX(dquot->dq_id, depth)] = cpu_to_le32(0);
-		for (i = 0; i < V2_DQBLKSIZE && !buf[i]; i++);	/* Block got empty? */
+		for (i = 0; i < V2_DQBLKSIZE && !buf[i]; i++)
+			;	/* Block got empty? */
 		if (i == V2_DQBLKSIZE) {
 			put_free_dqblk(filp, dquot->dq_type, buf, *blk);
 			*blk = 0;
-		}
-		else
-			if ((ret = write_blk(filp, *blk, buf)) < 0)
+		} else if ((ret = write_blk(filp, *blk, buf)) < 0)
 				printk(KERN_ERR "VFS: Can't write quota tree block %u.\n", *blk);
 	}
 out_buf:
@@ -584,6 +589,12 @@
 }
 
 /* Find entry for given id in the tree */
+
+/**
+ * Recursion count equals V2_DQTREEDEPTH, keep both in sync
+ * RECURSION:	4
+ * STEP:	find_tree_dqentry
+ */
 static loff_t find_tree_dqentry(struct dquot *dquot, uint blk, int depth)
 {
 	struct file *filp = sb_dqopt(dquot->dq_sb)->files[dquot->dq_type];
--- linux-2.6.6stack/drivers/char/random.c~recursion	2004-05-10 18:10:23.000000000 +0200
+++ linux-2.6.6stack/drivers/char/random.c	2004-05-30 18:48:55.000000000 +0200
@@ -1311,6 +1311,12 @@
  * from the primary pool to the secondary extraction pool. We make
  * sure we pull enough for a 'catastrophic reseed'.
  */
+
+/** 
+ * RECURSION:	2
+ * STEP:	xfer_secondary_pool
+ * STEP:	extract_entropy
+ */
 static inline void xfer_secondary_pool(struct entropy_store *r,
 				       size_t nbytes, __u32 *tmp)
 {
--- linux-2.6.6stack/drivers/ide/ide-timing.h~recursion	2004-01-09 07:59:26.000000000 +0100
+++ linux-2.6.6stack/drivers/ide/ide-timing.h	2004-05-31 16:56:23.000000000 +0200
@@ -208,63 +208,53 @@
 	return t; 
 }
 
+/**
+ * RECURSION:	2
+ * STEP:	ide_timing_compute
+ */
 static int ide_timing_compute(ide_drive_t *drive, short speed, struct ide_timing *t, int T, int UT)
 {
 	struct hd_driveid *id = drive->id;
 	struct ide_timing *s, p;
 
-/*
- * Find the mode.
- */
-
-	if (!(s = ide_timing_find_mode(speed)))
+	s = ide_timing_find_mode(speed);
+	if (!s)
 		return -EINVAL;
 
-/*
- * If the drive is an EIDE drive, it can tell us it needs extended
- * PIO/MWDMA cycle timing.
- */
-
-	if (id && id->field_valid & 2) {	/* EIDE drive */
-
+	/* If the drive is an EIDE drive, it can tell us it needs extended
+	 * PIO/MWDMA cycle timing.
+	 */
+	if (id && (id->field_valid & 2)) {	/* EIDE drive */
 		memset(&p, 0, sizeof(p));
 
 		switch (speed & XFER_MODE) {
+		case XFER_PIO:
+			if (speed <= XFER_PIO_2)
+				p.cycle = p.cyc8b = id->eide_pio;
+			else
+				p.cycle = p.cyc8b = id->eide_pio_iordy;
+			break;
 
-			case XFER_PIO:
-				if (speed <= XFER_PIO_2) p.cycle = p.cyc8b = id->eide_pio;
-						    else p.cycle = p.cyc8b = id->eide_pio_iordy;
-				break;
-
-			case XFER_MWDMA:
-				p.cycle = id->eide_dma_min;
-				break;
+		case XFER_MWDMA:
+			p.cycle = id->eide_dma_min;
+			break;
 		}
-
 		ide_timing_merge(&p, t, t, IDE_TIMING_CYCLE | IDE_TIMING_CYC8B);
 	}
 
-/*
- * Convert the timing to bus clock counts.
- */
-
+	/* Convert the timing to bus clock counts. */
 	ide_timing_quantize(s, t, T, UT);
 
-/*
- * Even in DMA/UDMA modes we still use PIO access for IDENTIFY, S.M.A.R.T
- * and some other commands. We have to ensure that the DMA cycle timing is
- * slower/equal than the fastest PIO timing.
- */
-
+	/* Even in DMA/UDMA modes we still use PIO access for IDENTIFY,
+	 * S.M.A.R.T and some other commands. We have to ensure that the
+	 * DMA cycle timing is slower/equal than the fastest PIO timing.
+	 */
 	if ((speed & XFER_MODE) != XFER_PIO) {
 		ide_timing_compute(drive, ide_find_best_mode(drive, XFER_PIO | XFER_EPIO), &p, T, UT);
 		ide_timing_merge(&p, t, t, IDE_TIMING_ALL);
 	}
 
-/*
- * Lenghten active & recovery time so that cycle time is correct.
- */
-
+	/* Lenghten active & recovery time so that cycle time is correct. */
 	if (t->act8b + t->rec8b < t->cyc8b) {
 		t->act8b += (t->cyc8b - (t->act8b + t->rec8b)) / 2;
 		t->rec8b = t->cyc8b - t->act8b;
--- linux-2.6.6stack/drivers/ide/ide-tape.c~recursion	2004-05-10 18:10:24.000000000 +0200
+++ linux-2.6.6stack/drivers/ide/ide-tape.c	2004-05-31 16:58:30.000000000 +0200
@@ -3653,6 +3653,11 @@
  *	the filemark is in our internal pipeline even if the tape doesn't
  *	support spacing over filemarks in the reverse direction.
  */
+
+/**
+ * RECURSION:	2
+ * STEP:	idetape_space_over_filemarks
+ */
 static int idetape_space_over_filemarks (ide_drive_t *drive,short mt_op,int mt_count)
 {
 	idetape_tape_t *tape = drive->driver_data;
@@ -3711,21 +3716,21 @@
 	 *	Now we can issue the space command.
 	 */
 	switch (mt_op) {
-		case MTFSF:
-		case MTBSF:
-			idetape_create_space_cmd(&pc,mt_count-count,IDETAPE_SPACE_OVER_FILEMARK);
-			return (idetape_queue_pc_tail(drive, &pc));
-		case MTFSFM:
-		case MTBSFM:
-			if (!tape->capabilities.sprev)
-				return (-EIO);
-			retval = idetape_space_over_filemarks(drive, MTFSF, mt_count-count);
-			if (retval) return (retval);
-			count = (MTBSFM == mt_op ? 1 : -1);
-			return (idetape_space_over_filemarks(drive, MTFSF, count));
-		default:
-			printk(KERN_ERR "ide-tape: MTIO operation %d not supported\n",mt_op);
+	case MTFSF:
+	case MTBSF:
+		idetape_create_space_cmd(&pc,mt_count-count,IDETAPE_SPACE_OVER_FILEMARK);
+		return (idetape_queue_pc_tail(drive, &pc));
+	case MTFSFM:
+	case MTBSFM:
+		if (!tape->capabilities.sprev)
 			return (-EIO);
+		retval = idetape_space_over_filemarks(drive, MTFSF, mt_count-count);
+		if (retval) return (retval);
+		count = (MTBSFM == mt_op ? 1 : -1);
+		return (idetape_space_over_filemarks(drive, MTFSF, count));
+	default:
+		printk(KERN_ERR "ide-tape: MTIO operation %d not supported\n",mt_op);
+		return (-EIO);
 	}
 }
 
--- linux-2.6.6stack/drivers/isdn/i4l/isdn_tty.c~recursion	2004-03-28 21:51:38.000000000 +0200
+++ linux-2.6.6stack/drivers/isdn/i4l/isdn_tty.c	2004-05-31 17:02:39.000000000 +0200
@@ -2519,6 +2519,11 @@
  * For RING-message handle auto-ATA if register 0 != 0
  */
 
+/**
+ * RECURSION:	2
+ * STEP:	isdn_tty_modem_result
+ * STEP:	isdn_tty_cmd_ATA
+ */
 static void
 isdn_tty_modem_result(int code, modem_info * info)
 {
--- linux-2.6.6stack/drivers/isdn/icn/icn.c~recursion	2004-03-28 21:51:38.000000000 +0200
+++ linux-2.6.6stack/drivers/isdn/icn/icn.c	2004-05-31 17:03:55.000000000 +0200
@@ -1097,6 +1097,11 @@
 /*
  * Delete card's pending timers, send STOP to linklevel
  */
+
+/**
+ * RECURSION:	2
+ * STEP:	icn_stopcard
+ */
 static void
 icn_stopcard(icn_card * card)
 {

Re: [RFC PATCH] explicitly mark recursion count

[Pavel Machek]

Hi!

> > So effectively, it comes down to the recursive paths.  Unless someone
> > comes up with a semantical parser that can figure out the maximum
> > number of iterations, we have to look at them manually.
> 
> Linus, Andrew, would you accept patches like the one below?  With such
> information and assuming that the comments will get maintained, it's
> relatively simple to unroll recursions and measure stack comsumption
> more accurately.

Perhaps some other format of comment should be introduced? Will not
this interfere with linuxdoc?
								Pavel

-- 
934a471f20d6580d5aad759bf0d97ddc

Re: [RFC PATCH] explicitly mark recursion count

[viro]

On Tue, Jun 01, 2004 at 08:02:05AM +0200, Jörn Engel wrote:
> Add recursion markers to teach automated test tools how bad documented
> recursions really are.  Currently, there is only a single such too that
> can use the information and there is always the danger of documentation
> and reality getting out of sync.  But until there's a better tool...
 
> +/**
> + * RECURSION:	100
> + * STEP:	register_proc_table
> + */

This is too ugly for words ;-/  Who will maintain that data, anyway?

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Tue, 1 June 2004 13:39:22 +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
>  
> > +/**
> > + * RECURSION:	100
> > + * STEP:	register_proc_table
> > + */
> 
> This is too ugly for words ;-/  Who will maintain that data, anyway?

What format do you propose?  I don't care too much.

Maintenance would get easier with less recursions, obviously. ;)

I could hack up something that will generate digests from the function
source code (through smatch or so) and put those digests into the
comments.  As long as they match, the comments remain valid.  And that
should get past lawyers, as I work on a different basis now.

Jörn

-- 
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Tue, 1 June 2004 14:20:13 +0200, Pavel Machek wrote:
> 
> Perhaps some other format of comment should be introduced? Will not
> this interfere with linuxdoc?

I'm open for suggestions. ;)

Jörn

-- 
Data dominates. If you've chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.
-- Rob Pike

Re: [RFC PATCH] explicitly mark recursion count

[Pavel Machek]

Hi!

> > Perhaps some other format of comment should be introduced? Will not
> > this interfere with linuxdoc?
> 
> I'm open for suggestions. ;)

/*! Recursion-count: 2 Whatever-else: 5 */

?
								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Tue, 1 June 2004 15:32:29 +0200, Pavel Machek wrote:
> > 
> > I'm open for suggestions. ;)
> 
> /*! Recursion-count: 2 Whatever-else: 5 */

What I need is:
1. Recursion count
2. All functions involved in the recursion in the correct order (a
   calls b calls c calls d calls a, something like that).

How do you pass 2?

Jörn

-- 
ticks = jiffies;
while (ticks == jiffies);
ticks = jiffies;
-- /usr/src/linux/init/main.c

Re: [RFC PATCH] explicitly mark recursion count

[Horst von Brand]

Pavel Machek <pavel@suse.cz> said:
> =?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de> said:
> > > So effectively, it comes down to the recursive paths.  Unless someone
> > > comes up with a semantical parser that can figure out the maximum
> > > number of iterations, we have to look at them manually.

> > Linus, Andrew, would you accept patches like the one below?  With such
> > information and assuming that the comments will get maintained, it's
> > relatively simple to unroll recursions and measure stack comsumption
> > more accurately.
> 
> Perhaps some other format of comment should be introduced? Will not
> this interfere with linuxdoc?

If the comment gets out of sync, you are toast. Too easy for that to
happen, IMVHO.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [RFC PATCH] explicitly mark recursion count

[Horst von Brand]

=?iso-8859-1?Q?J=F6rn?= Engel <joern@wohnheim.fh-wedel.de> said:

[...]

> What I need is:
> 1. Recursion count

How do you know the limit is enforced? By guessing?

> 2. All functions involved in the recursion in the correct order (a
>    calls b calls c calls d calls a, something like that).

But also b calls f calls g...

Maintaining the full possible-call-graph is a _huge_ job, better done
automatically (because somebody _will_screw up when doing it by hand). Plus
the fun "structure spicked with all sorts of function pointers" object
implementation in the kernel... note that your carefully maintained call
graph/counts can be screwed up royally by any random third-party device
driver or filesystem module.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [RFC PATCH] explicitly mark recursion count

[Linus Torvalds]

On Tue, 1 Jun 2004, Horst von Brand wrote:
> 
> If the comment gets out of sync, you are toast. Too easy for that to
> happen, IMVHO.

Yes.

Recursion should be detectable automatically, the only thing you can't 
detect easily is the reason to _break_ recursion. 

So how about just having a simple loop finder, and then the only comment 
you need is a simple /* max recursion: N */ for any point in the loop.

That still makes it interesting if one function is part of two loops, and
is logically the place that breaks the recursion for one (or both - with
different logic) of them. But does that actually happen?

			Linus

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Tue, 1 June 2004 12:58:12 -0700, Linus Torvalds wrote:
> On Tue, 1 Jun 2004, Horst von Brand wrote:
> > 
> > If the comment gets out of sync, you are toast. Too easy for that to
> > happen, IMVHO.
> 
> Yes.
> 
> Recursion should be detectable automatically, the only thing you can't 
> detect easily is the reason to _break_ recursion. 

Correct.  My tool already detects recursions and prints warning, it
just cannot make out the harmful ones and gives a warning for each.

> So how about just having a simple loop finder, and then the only comment 
> you need is a simple /* max recursion: N */ for any point in the loop.

That's what I basically want, at least for trivial recursions with
only one function involved.

For a->b->c->a type recursions, I also need to identify all involved
functions in the correct order, that's where my ugly format comes
from.

RECURSION:	2
STEP:	a
STEP:	b
STEP:	c

This mean that the recursion from a to b to c and back can happen
twice at most.

Sure, the format is ugly.  If anyone really cares I can change it into
any other.  But it gets the job done, so I don't care.

> That still makes it interesting if one function is part of two loops, and
> is logically the place that breaks the recursion for one (or both - with
> different logic) of them. But does that actually happen?

"Interesting" is the wrong word, really.  Imo it doesn't make any
sense to write such code and therefore I don't want to deal with it
either.  Print a warning and be done with it.  See my output:

WARNING: multiple recursions around check_sig()

Jörn

-- 
A victorious army first wins and then seeks battle.
-- Sun Tzu

Re: [RFC PATCH] explicitly mark recursion count

[Linus Torvalds]

On Wed, 2 Jun 2004, Jörn Engel wrote:
> 
> For a->b->c->a type recursions, I also need to identify all involved
> functions in the correct order, that's where my ugly format comes
> from.

Why?

You really only need to know that _one_ of the entries break the 
recursion, and you need to know what the break depth is for that one 
entry.

So for example, if "c" is annotated with "max recursion: 5", then you know 
that the above loop will recurse at most 5 times.

I don't see why you need any other information.

			Linus

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 07:15:07 -0700, Linus Torvalds wrote:
> On Wed, 2 Jun 2004, Jörn Engel wrote:
> > 
> > For a->b->c->a type recursions, I also need to identify all involved
> > functions in the correct order, that's where my ugly format comes
> > from.
> 
> Why?
> 
> You really only need to know that _one_ of the entries break the 
> recursion, and you need to know what the break depth is for that one 
> entry.
> 
> So for example, if "c" is annotated with "max recursion: 5", then you know 
> that the above loop will recurse at most 5 times.
> 
> I don't see why you need any other information.

Then you see something I don't see.  For example there are quite a few
recursions with some function like

void foo(int depth)
{
	if (!depth) {
		bar(1);
	}
	...
}

bar will, maybe through several more functions call foo(1).

How can you say that foo will beak this recursion after two rounds
max?  What if a changed bar decrements the depth value?  The recursion
will run for infinity now, won't it?  And whoever changed bar doesn't
have a clue that he now fucked up your comment to foo.

I claim:
There is no way to tell the depth of any recursion without looking at
all involved functions.

Prove me wrong, please.

Jörn

-- 
When in doubt, use brute force.
-- Ken Thompson

Re: [RFC PATCH] explicitly mark recursion count

[Davide Libenzi]

On Wed, 2 Jun 2004, Linus Torvalds wrote:

> On Wed, 2 Jun 2004, Jörn Engel wrote:
> > 
> > For a->b->c->a type recursions, I also need to identify all involved
> > functions in the correct order, that's where my ugly format comes
> > from.
> 
> Why?
> 
> You really only need to know that _one_ of the entries break the 
> recursion, and you need to know what the break depth is for that one 
> entry.
> 
> So for example, if "c" is annotated with "max recursion: 5", then you know 
> that the above loop will recurse at most 5 times.
> 
> I don't see why you need any other information.

Hmmm, I see more data to maintain to support a method that will never be 
even close to be perfect. How the thing works with callback triggered 
loops for example, where a function is not directly called, but instead is 
passed to another function (that maybe pass it to another function) that 
triggers the call. Or maybe it's another set of functions that might 
trigger the call (think about all *_operations for example). Eg, there's 
an evident loop possibility in epoll (triggered by callback'd wakeups) 
that is not in the list, and it's pretty hard to detect. Doing stack usage 
analisys from the source code is not easy, once you abbandon the trivial 
direct call scenario.



- Davide

Re: [RFC PATCH] explicitly mark recursion count

[Linus Torvalds]

On Wed, 2 Jun 2004, Jörn Engel wrote:
> 
> Then you see something I don't see.  For example there are quite a few
> recursions with some function like
> 
> void foo(int depth)
> {
> 	if (!depth) {
> 		bar(1);
> 	}
> 	...
> }
> 
> bar will, maybe through several more functions call foo(1).
> 
> How can you say that foo will beak this recursion after two rounds
> max?

The programmer had _better_ know that there is some upper limit.

> I claim:
> There is no way to tell the depth of any recursion without looking at
> all involved functions.

And I claim: recursion is illegal unless the programmer has some explicit 
recursion limiter. And if he has that recursion limiter in one of the 
functions, then he damn well better know it, and know the value it limits 
recursion to.

		Linus

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 07:45:10 -0700, Linus Torvalds wrote:
> 
> The programmer had _better_ know that there is some upper limit.
> 
> And I claim: recursion is illegal unless the programmer has some explicit 
> recursion limiter. And if he has that recursion limiter in one of the 
> functions, then he damn well better know it, and know the value it limits 
> recursion to.

Can I read this as:
Linus himself will use strong words to enforce all recursions in the
kernel to be either removed or properly documented.

In that case, you have 273 recursions to deal with.  They are all in
the data I attached a few posts back.  Recursions would basically be
in the same league as huge stack hogs, sounds good.

Jörn

-- 
Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface. 
-- Doug MacIlroy

Re: [RFC PATCH] explicitly mark recursion count

[Linus Torvalds]

On Wed, 2 Jun 2004, Jörn Engel wrote:
> 
> Can I read this as:
> Linus himself will use strong words to enforce all recursions in the
> kernel to be either removed or properly documented.

If we have a good detector that is reliable and easy to run, why not?

It will take some time, but I think the problem so far has been that the
recursion can be hard to see. Some "core" cases are well-known (memory
allocations during memory allocation, and filename lookup), and they 
should be trivial to annotate. Knock wood. Others might be worse.

> In that case, you have 273 recursions to deal with.  They are all in
> the data I attached a few posts back.  Recursions would basically be
> in the same league as huge stack hogs, sounds good.

Yes. And with huge stack hogs, we've not exactly "fixed them all in a 
weekend", have we? But having a few people run the checking tools and 
nagging every once in a while ends up eventually fixing things. At least 
the most common ones.

		Linus

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 08:12:00 -0700, Linus Torvalds wrote:
> On Wed, 2 Jun 2004, Jörn Engel wrote:
> > 
> > Can I read this as:
> > Linus himself will use strong words to enforce all recursions in the
> > kernel to be either removed or properly documented.
> 
> If we have a good detector that is reliable and easy to run, why not?

Great!  So the official format to document recursions is plain english
for human readers?

> It will take some time, but I think the problem so far has been that the
> recursion can be hard to see. Some "core" cases are well-known (memory
> allocations during memory allocation, and filename lookup), and they 
> should be trivial to annotate. Knock wood. Others might be worse.

For sure.  There are some functions with multiple recursions around
them, real fun! :)

> > In that case, you have 273 recursions to deal with.  They are all in
> > the data I attached a few posts back.  Recursions would basically be
> > in the same league as huge stack hogs, sounds good.
> 
> Yes. And with huge stack hogs, we've not exactly "fixed them all in a 
> weekend", have we? But having a few people run the checking tools and 
> nagging every once in a while ends up eventually fixing things. At least 
> the most common ones.

s/a few people/Jörn/

Legal reasons.  I'll try to do this from time to time.

Jörn

-- 
To recognize individual spam features you have to try to get into the
mind of the spammer, and frankly I want to spend as little time inside
the minds of spammers as possible.
-- Paul Graham

Re: [RFC PATCH] explicitly mark recursion count

[Linus Torvalds]

On Wed, 2 Jun 2004, Jörn Engel wrote:
> > 
> > If we have a good detector that is reliable and easy to run, why not?
> 
> Great!  So the official format to document recursions is plain english
> for human readers?

Actually, I'd suggest making it a preprocessor directive at the very top
of the function itself. That way I can make sparse parse it too if I ever
want to.

So something like

	/*
	 * This function is part of recursion, but we limit
	 * the depth with the "depth" parameter to 5
	 */
	int my_recursive_function(int depth, struct datastruct *arg)
	{
		declare_recursion_depth(5);
		...

where we could either just #define it to some no-op like

	#define declare_recursion_depth(x) \
		extern void __dummy_function_never_used()

or even do something fancier:

	#define declare_recursion_depth(x) \
		static __init char recursion[] = __FILE__ ":" __FUNCTION__ "=" #x;

which will generate a nice clean variable that shows up in "objdump" in 
all its glory, so that pretty much any tool can trivially parse it.

And for something like sparse or other automated tools, we can trivially 
make it be something more appropriate, ie

	#define recursion_depth(x) \
		__builtin_recursion_depth(x)

or whatever checker-specific thing we want it to be.

And other tools should be equally able to easily pick it up, either by 
just looking at the object file or re-defining the macro to suit 
themselves.

I think the above syntax is both human-readable and "obviously parseable" 
in many trivial ways. Whaddaya think? Works for you?

		Linus

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 08:52:53 -0700, Linus Torvalds wrote:
> 
> I think the above syntax is both human-readable and "obviously parseable" 
> in many trivial ways. Whaddaya think? Works for you?

Works for me for trivial recursions (just one function involved.  With
a little more pain, it should work for basically everything.  Only
exception are multiple recursions around the same function.  So unless
you like to keep those suckers, I'm fine with it.

Jörn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories

Re: [RFC PATCH] explicitly mark recursion count

[Linus Torvalds]

On Wed, 2 Jun 2004, Jörn Engel wrote:
> 
> Works for me for trivial recursions (just one function involved.  With
> a little more pain, it should work for basically everything.  Only
> exception are multiple recursions around the same function.  So unless
> you like to keep those suckers, I'm fine with it.

Well, multiple recursion around the same function seems to be solvable two 
different ways:
 - "don't do that then". It really seems broken, but maybe there are 
   really really good reasons _why_ it's not broken and why it happens.
 - make sure that the separate loops are broken in some _other_ place than 
   in the function they share.

A combination of the two may work well.

I say "may", because maybe I'm wrong, and the condition is common and hard
to avoid limiting in the shared function. I don't have your data (and I'm
lazy, so quite frankly I'd much rather you do the analysis anyway ;).

That said, I just don't see any sane alternatives to my "break in one
place" thing. I believe that anything more complex that tries to explain
the whole loop is just going to be a nightmare to maintain, and fragile as
hell except for totally static legacy code that nobody touches any more.

			Linus

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 09:25:50 -0700, Linus Torvalds wrote:
> 
> Well, multiple recursion around the same function seems to be solvable two 
> different ways:
>  - "don't do that then". It really seems broken, but maybe there are 
>    really really good reasons _why_ it's not broken and why it happens.
>  - make sure that the separate loops are broken in some _other_ place than 
>    in the function they share.
> 
> A combination of the two may work well.
> 
> I say "may", because maybe I'm wrong, and the condition is common and hard
> to avoid limiting in the shared function. I don't have your data (and I'm
> lazy, so quite frankly I'd much rather you do the analysis anyway ;).

You *do* have my data, but I buy the lazy argument. ;)

> That said, I just don't see any sane alternatives to my "break in one
> place" thing. I believe that anything more complex that tries to explain
> the whole loop is just going to be a nightmare to maintain, and fragile as
> hell except for totally static legacy code that nobody touches any more.

Amen, brother.  Anything complicated will contain bugs tomorrow, if
not already today.

Let's see.  Right now, we have two cases of multiple recursions:
WARNING: multiple recursions around check_sig()
WARNING: multiple recursions around usb_audio_recurseunit()

check_sig() is bad code and can be cleaned up.

Leaves usb_audio_recurseunit() as the only function in question, that
one could actually be sane, although it looks rather interesting:
WARNING: trivial recursion detected:
       0  usb_audio_recurseunit
WARNING: recursion detected:
      16  usb_audio_selectorunit
       0  usb_audio_recurseunit
WARNING: multiple recursions around usb_audio_recurseunit()
WARNING: recursion detected:
       0  usb_audio_recurseunit
       0  usb_audio_processingunit

Greg, can you say whether this construct makes sense?

Jörn

-- 
Eighty percent of success is showing up.
-- Woody Allen

Re: [RFC PATCH] explicitly mark recursion count

[Greg KH]

On Wed, Jun 02, 2004 at 07:17:32PM +0200, J?rn Engel wrote:
> 
> Leaves usb_audio_recurseunit() as the only function in question, that
> one could actually be sane, although it looks rather interesting:
> WARNING: trivial recursion detected:
>        0  usb_audio_recurseunit
> WARNING: recursion detected:
>       16  usb_audio_selectorunit
>        0  usb_audio_recurseunit
> WARNING: multiple recursions around usb_audio_recurseunit()
> WARNING: recursion detected:
>        0  usb_audio_recurseunit
>        0  usb_audio_processingunit
> 
> Greg, can you say whether this construct makes sense?

Well it's sane only if you think that USB descriptors can be sane :)

Anyway, this loop will always terminate as we have a finite sized USB
descriptor that this function is parsing.  As to how many times we will
recurse, I don't really know as I haven't spent much time looking into
the different messed up USB audio devices out there on the market...

Sorry I can't be of more help, but I don't think you need to worry about
this function.

thanks,

greg k-h

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 10:32:00 -0700, Greg KH wrote:
> On Wed, Jun 02, 2004 at 07:17:32PM +0200, J?rn Engel wrote:
> > 
> > Leaves usb_audio_recurseunit() as the only function in question, that
> > one could actually be sane, although it looks rather interesting:
> > WARNING: trivial recursion detected:
> >        0  usb_audio_recurseunit
> > WARNING: recursion detected:
> >       16  usb_audio_selectorunit
> >        0  usb_audio_recurseunit
> > WARNING: multiple recursions around usb_audio_recurseunit()
> > WARNING: recursion detected:
> >        0  usb_audio_recurseunit
> >        0  usb_audio_processingunit
> > 
> > Greg, can you say whether this construct makes sense?
> 
> Well it's sane only if you think that USB descriptors can be sane :)
> 
> Anyway, this loop will always terminate as we have a finite sized USB
> descriptor that this function is parsing.  As to how many times we will
> recurse, I don't really know as I haven't spent much time looking into
> the different messed up USB audio devices out there on the market...
> 
> Sorry I can't be of more help, but I don't think you need to worry about
> this function.

That's ok.  At least you can talk about that code without obvious
disgust, which is a quality criterium in itself.

Leaves exactly one multiply recursive function we might want to keep.
So I just won't worry too much and ignore the warnings about it, fine.

Jörn

-- 
ticks = jiffies;
while (ticks == jiffies);
ticks = jiffies;
-- /usr/src/linux/init/main.c

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 07:35:39 -0700, Davide Libenzi wrote:
> 
> Hmmm, I see more data to maintain to support a method that will never be 
> even close to be perfect.

You get it wrong.  This is mainly about Bad Code or Insufficient
Documentation.  In general, I want recursions to be removed, full
stop.  So there is not more data, but less.

If the recursion is actually wanted, then those cases should either be
so few and obvious that a single person can explain them all from
memory.  That, or things have to be written down somehow and unless
you have a better suggestion, any format is better than nothing.

Jörn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."

Re: [RFC PATCH] explicitly mark recursion count

[Davide Libenzi]

On Wed, 2 Jun 2004, [iso-8859-1] Jörn Engel wrote:

> On Wed, 2 June 2004 07:35:39 -0700, Davide Libenzi wrote:
> > 
> > Hmmm, I see more data to maintain to support a method that will never be 
> > even close to be perfect.
> 
> You get it wrong.  This is mainly about Bad Code or Insufficient
> Documentation.  In general, I want recursions to be removed, full
> stop.  So there is not more data, but less.

You're requesting to add and maintain data to feed a tool that catches 
only trivially visible recursion. I don't want to waste mine and your time 
explaining why your tool will never work, but if you want an hint, you can 
start thinking about all functions that sets/pass callbacks and/or sets 
operational functions. I don't know if you noticed that, but Linux is 
heavily function-pointer driven. Eg, one function setups a set of function 
pointers, and another 317 indirectly calls them. Having such comments, not 
only makes the maintainance heavier, but gives the false sense of safeness 
that once you drop that data in, you're protected against recursion.



- Davide

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 11:37:50 -0700, Davide Libenzi wrote:
> 
> You're requesting to add and maintain data to feed a tool that catches 
> only trivially visible recursion. I don't want to waste mine and your time 
> explaining why your tool will never work, but if you want an hint, you can 
> start thinking about all functions that sets/pass callbacks and/or sets 
> operational functions. I don't know if you noticed that, but Linux is 
> heavily function-pointer driven. Eg, one function setups a set of function 
> pointers, and another 317 indirectly calls them. Having such comments, not 
> only makes the maintainance heavier, but gives the false sense of safeness 
> that once you drop that data in, you're protected against recursion.

Yeah, I know about the problems to generate a complete call graph.
With function pointers, it is plain impossible to get it right in the
most general case.

Note the "in the most general case" part.  You can get things right if
you make some assumptions and those assumptions are actually valid.
In my case the assumptions are:
1. all relevant function pointers are stuffed into some struct and
2. no casts are used to disguise function pointer as something else.

If you stick with those rules, the resulting code is quite sane, which
is much more important than any tools being usable.  If the kernel
doesn't stick to those rules for a good reason, I'd like to know about
it, so I can adjust my tool.  And if the kernel doesn't stick to those
rules for no good reason, the code if broken and needs to be fixed.

Is this sane?

Jörn

-- 
A victorious army first wins and then seeks battle.
-- Sun Tzu

Re: [RFC PATCH] explicitly mark recursion count

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Wed, 02 Jun 2004 20:58:32 +0200, =?iso-8859-1?Q?J=F6rn?= Engel said:

> Note the "in the most general case" part.  You can get things right if
> you make some assumptions and those assumptions are actually valid.
> In my case the assumptions are:
> 1. all relevant function pointers are stuffed into some struct and
> 2. no casts are used to disguise function pointer as something else.

That seems to be reasonable.  And if we're aliasing, or shadowing, or casting
function pointers to something else, or using a union to overlay it, that's
just a time bomb waiting to explode.  At the very least, such code should
require a large "Danger! Here be large and nasty dragons!" marker.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RFC PATCH] explicitly mark recursion count

[viro]

On Wed, Jun 02, 2004 at 08:58:32PM +0200, Jörn Engel wrote:
> Note the "in the most general case" part.  You can get things right if
> you make some assumptions and those assumptions are actually valid.
> In my case the assumptions are:
> 1. all relevant function pointers are stuffed into some struct and

Wrong.  They are often passed as arguments to generic helpers, without
being ever put into any structures.

Re: 4k stacks in 2.6

[Bill Davidsen]

Andrea Arcangeli wrote:
> On Thu, May 27, 2004 at 04:03:22PM +0200, Arjan van de Ven wrote:
> 
>>In theory you are absolutely right, problem is the current macro..... it's
>>SO much easier to have one stacksize everywhere (and cheaper too) for
>>this... (and it hasn't been a problem so far, esp since the softirq's have
> 
> 
> I see the problem, but then why don't we wait to implement it right, to
> allow 8k irq-stacks before merging into mainline?
> 
> grep for "~s 4k" (i.e. the word "4[kK]" in the subject) on l-k and
> you'll see there's more than just nvidia. one user reported not being
> able to boot at all with 4k stacks since 2.6.6 doesn't have a stack
> overflow in the oops, so I hope he tested w/ and w/o 4KSTACKS option
> enabled to be able to claim what broke his machine is the 4KSTACKS
> option. (his oops doesn't reveal a stack overflow, the thread_info is at
> 0xf000 and the esp is at 0xffxx)
> 
> Making it a config option, is a sort of proof that you agree it can
> break something, or you wouldn't make it a config option in the first
> place. What's the point of making it a configuration option if it cannot
> break anything and if it's not risky? Making it a config option is not
> good, because then some developer may develop leaving 4KSTACKS disabled,
> and then his kernel code might break on the users with 4KSTACKS enabled
> (it's not much different from PREEMPT).  Amittedly code that overflows
> 4k is likely to be not legitimate but not all code is good (the most
> common error is to allocate big strutures locally on the stack with
> local vars), and if developers are able to notice the overflow on their
> own testing it's better.

We have lots of options which may cause problems but are useful for 
special situations, why is this one any different? The only actual 
benefit I've seen quoted for 4k stack is that it improves fork 
performance if memory is so fragmented that there is no 8k block left. 
And my first thought on hearing that was if that's common the VM should 
be investigated. This is a stable kernel, and breaking even such an 
abomination as a binary-only driver for the sake of whoever has this 
vastly fragmented memory seems to be the anthesis of stable.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 20:37:20 +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Jun 02, 2004 at 08:58:32PM +0200, Jörn Engel wrote:
> > Note the "in the most general case" part.  You can get things right if
> > you make some assumptions and those assumptions are actually valid.
> > In my case the assumptions are:
> > 1. all relevant function pointers are stuffed into some struct and
> 
> Wrong.  They are often passed as arguments to generic helpers, without
> being ever put into any structures.

Ok.  Would it be ok to use the following then?

b1. Function pointer are passed as arguments to functions and
b2. those pointer are called directly from the function, they are
    passed to.

Either that or the previous two rules, renamed to a1 and a2.

(Note that I care more about sane rules than what any random code in
some dark corner happens to do right now.)

Jörn

-- 
A surrounded army must be given a way out.
-- Sun Tzu

Re: [RFC PATCH] explicitly mark recursion count

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Wed, 02 Jun 2004 20:37:20 BST, viro@parcelfarce.linux.theplanet.co.uk said:

> Wrong.  They are often passed as arguments to generic helpers, without
> being ever put into any structures.

At least those can *hopefully* be automatically detected by looking at the
function's definition.  Are there any known cases where they're "passed
through" from caller to generic_a to generic_b which ends up calling the
function via pointer, or is it restricted to caller, generic_a, *(pointer)?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RFC PATCH] explicitly mark recursion count

[viro]

On Wed, Jun 02, 2004 at 09:45:15PM +0200, Jörn Engel wrote:
> On Wed, 2 June 2004 20:37:20 +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> > On Wed, Jun 02, 2004 at 08:58:32PM +0200, Jörn Engel wrote:
> > > Note the "in the most general case" part.  You can get things right if
> > > you make some assumptions and those assumptions are actually valid.
> > > In my case the assumptions are:
> > > 1. all relevant function pointers are stuffed into some struct and
> > 
> > Wrong.  They are often passed as arguments to generic helpers, without
> > being ever put into any structures.
> 
> Ok.  Would it be ok to use the following then?
> 
> b1. Function pointer are passed as arguments to functions and
> b2. those pointer are called directly from the function, they are
>     passed to.

Again not guaranteed to be true - they can be (and often are) passed further.

Moreover, they are also stored untyped in structures.  Common pattern
is
	foo.callback = f;
	foo.argument = p;
	iterate_over_blah(blah, &foo);

Note that here f is the only thing that will see the value of p _and_ the
only thing that cares about type of p.  iterator itself doesn't care and
can be used for different types.

Re: [RFC PATCH] explicitly mark recursion count

[Davide Libenzi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1644 bytes --]

On Wed, 2 Jun 2004, [iso-8859-1] Jörn Engel wrote:

> Yeah, I know about the problems to generate a complete call graph.
> With function pointers, it is plain impossible to get it right in the
> most general case.
> 
> Note the "in the most general case" part.  You can get things right if
> you make some assumptions and those assumptions are actually valid.
> In my case the assumptions are:
> 1. all relevant function pointers are stuffed into some struct and
> 2. no casts are used to disguise function pointer as something else.
> 
> If you stick with those rules, the resulting code is quite sane, which
> is much more important than any tools being usable.  If the kernel
> doesn't stick to those rules for a good reason, I'd like to know about
> it, so I can adjust my tool.  And if the kernel doesn't stick to those
> rules for no good reason, the code if broken and needs to be fixed.
> 
> Is this sane?

Think at file_operations as very simple example, and try to find out what 
is actually called when somewhere the code does f_op->*(). How would you 
build the graph down there. You'd have to record all the functions that 
have been assigned to such method throughout the code, and nest *all* 
their graph in place. And this will eventually trigger false positives. 
Similar thing with functions that accepts callbacks, either directly or 
inside structures. And this doesn't even start to take aliasing into 
account. Hunting stack hungry functions is very good, and having a tool 
that is maybe 60% precise in detecting loops is fine too. But requiring 
metadata to be maintained to support such tool is IMO wrong.



- Davide

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 20:59:44 +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> > 
> > Ok.  Would it be ok to use the following then?
> > 
> > b1. Function pointer are passed as arguments to functions and
> > b2. those pointer are called directly from the function, they are
> >     passed to.
> 
> Again not guaranteed to be true - they can be (and often are) passed further.

Hmm.  If that happens, I'm out of ideas for now.  Cannot do more than
give a warning.

> Moreover, they are also stored untyped in structures.  Common pattern
> is
> 	foo.callback = f;
> 	foo.argument = p;
> 	iterate_over_blah(blah, &foo);
> 
> Note that here f is the only thing that will see the value of p _and_ the
> only thing that cares about type of p.  iterator itself doesn't care and
> can be used for different types.

Those cases I should already catch.  If foo is of type "struct bar",
"bar.callback" will be the function name for a pseudo-function.  That
function is called by iterate_over_blah and calls f.  Unnamed struct
get a name made up from the components of the struct, like
____FAKE.Name.Chip.stat.Regi.LILP.Opti.high.lowe->ProcessIMQEntry.
Doesn't look pretty, but works.

Jörn

-- 
Time? What's that? Time is only worth what you do with it.
-- Theo de Raadt

Re: [RFC PATCH] explicitly mark recursion count

[Jörn Engel]

On Wed, 2 June 2004 16:20:24 -0700, Davide Libenzi wrote:
> 
> Think at file_operations as very simple example, and try to find out what 
> is actually called when somewhere the code does f_op->*(). How would you 
> build the graph down there. You'd have to record all the functions that 
> have been assigned to such method throughout the code, and nest *all* 
> their graph in place. And this will eventually trigger false positives. 

Bad example, I can deal with that just fine. :)
Any code calling f_op->read must not break for any f_op->read.  So it
is perfectly sane to assume that all get called.  I build the graph by
turning f_op->read into a pseudo-function that calls all functions
ever assigned to f_op->read.

> Similar thing with functions that accepts callbacks, either directly or 
> inside structures.

Those I only handle, if the callbacks are inside structures, true.
Will fix it when I find the time for it.

> And this doesn't even start to take aliasing into 
> account.

What exactly do you call aliasing?  Do you have an example?

> Hunting stack hungry functions is very good, and having a tool 
> that is maybe 60% precise in detecting loops is fine too. But requiring 
> metadata to be maintained to support such tool is IMO wrong.

Since Linus feels that said metadata is still useful without any
tools, I'll just ignore this objection. ;)

Still, some of the complaints were valid, thanks a bunch!  My todo
list has grown again.

Jörn

-- 
Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface. 
-- Doug MacIlroy

Re: 4k stacks in 2.6

[Timothy Miller]

Jörn Engel wrote:

> But I'll shut up now and see if I can generate better data over the
> weekend.  -test11 still had fun stuff like 3k stack consumption over
> some code paths in a pretty minimal kernel.  Wonder what 2.6.6 will do
> with allyesconfig. ;)

That gave me an idea.  Sometimes in chip design, we 'overconstrain' the 
logic synthesizer, because static timing analyzers often produce 
inaccurate results.  Anyhow, what if we were to go to 4K stacks but in 
static code analysis, flag anything which uses more than 2K or even 1K?

Re: 4k stacks in 2.6

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]


> That gave me an idea.  Sometimes in chip design, we 'overconstrain' the 
> logic synthesizer, because static timing analyzers often produce 
> inaccurate results.  Anyhow, what if we were to go to 4K stacks but in 
> static code analysis, flag anything which uses more than 2K or even 1K?

the patch I sent to akpm went to 400 bytes actually, but yeah, even that
already is debatable.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 4k stacks in 2.6

[Jörn Engel]

On Tue, 8 June 2004 08:26:25 +0200, Arjan van de Ven wrote:
> 
> > That gave me an idea.  Sometimes in chip design, we 'overconstrain' the 
> > logic synthesizer, because static timing analyzers often produce 
> > inaccurate results.  Anyhow, what if we were to go to 4K stacks but in 
> > static code analysis, flag anything which uses more than 2K or even 1K?

With 2.6.6, there are currently just a few non-recursive paths over
3k.  2k will give you a *lot* of output, but if you insist... ;)

http://wh.fh-wedel.de/~joern/data.nointermezzo.cs2.2k.bz2
470k compressed, 65M uncompressed

Feel free to send patches.

> the patch I sent to akpm went to 400 bytes actually, but yeah, even that
> already is debatable.

400 bytes?  That is for a single function, I assume.

Jörn

-- 
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu