ATTiny2313 ISR stack usage
Well, checking the ATTiny2313 documentation, on page 15, it states:


  The interrupt execution response for
  all the enabled AVR interrupts is four
  clock cycles minimum. After four clock
  cycles the program vector address for
  the actual interrupt handling routine
  is executed. During this four clock
  cycle period, the Program Counter is
  pushed onto the Stack. The vector is
  normally a jump to the interrupt
  routine, and this jump takes three
  clock cycles. If an interrupt occurs
  during execution of a multi-cycle
  instruction, this instruction is
  completed before the interrupt is
  served. If an interrupt occurs when
  the MCU is in sleep mode, the
  interrupt execution response time is
  increased by four clock cycles. This
  increase comes in addition to the
  start-up time from the selected sleep
  mode.
  
  A return from an interrupt handling
  routine takes four clock cycles.
  During these four clock cycles, the
  Program Counter (two bytes) is popped
  back from the Stack, the Stack Pointer
  is incremented by two, and the I-bit
  in SREG is set.


Thus you're really only looking at 2 bytes on the stack during an interrupt (the PC); anything else that an ISR puts on the stack is up to the ISR itself.  I wouldn't expect a well-written interrupt handler to need a whole lot of stack space.

As for the Stack Pointer itself, on page 13, it states:


  The Stack is mainly used for storing temporary data, for storing local 
  variables and for storing return addresses after interrupts and subroutine 
  calls. The Stack Pointer Register always points to the top of the Stack. 
  Note that the Stack is implemented as growing from higher memory locations 
  to lower memory locations. This implies that a Stack PUSH command decreases 
  the Stack Pointer.
  
  The Stack Pointer points to the data SRAM Stack area where the Subroutine 
  and Interrupt Stacks are located. This Stack space in the data SRAM must be 
  defined by the program before any subroutine calls are executed or interrupts 
  are enabled. The Stack Pointer must be set to point above 0x60. The Stack 
  Pointer is decremented by one when data is pushed onto the Stack with the PUSH 
  instruction, and it is decremented by two when the return address is pushed 
  onto the Stack with subroutine call or interrupt.  The Stack Pointer is 
  incremented by one when data is popped from the Stack with the POP instruction, 
  and it is incremented by two when data is popped from the Stack with 
  return from subroutine RET or return from interrupt RETI.
  
  The AVR Stack Pointer is implemented as two 8-bit registers in the I/O space. 
  The number of bits actually used is implementation dependent. Note that the 
  data space in some implementations of the AVR architecture is so small that 
  only SPL is needed. In this case, the SPH Register will not be present.


In your case, I think there's only SPL present (128 bytes of RAM = 7 bits).

Beyond the hardware, it depends upon your framework, which for most AVR parts is going to involve GCC, GNU Binutils, and avr-libc.  A quick look at the avr-libc FAQ turned up two good questions:

http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage


  What registers are used by the C compiler?
  
  
  Data types:
  char is 8 bits, int is 16 bits, long is 32 bits, long long is 64 bits, float and double are 32 bits (this is the only supported floating point format), pointers are 16 bits (function pointers are word addresses, to allow addressing up to 128K program memory space). There is a -mint8 option (see Options for the C compiler avr-gcc) to make int 8 bits, but that is not supported by avr-libc and violates C standards (int must be at least 16 bits). It may be removed in a future release.
  Call-used registers (r18-r27, r30-r31):
  May be allocated by gcc for local data. You may use them freely in assembler subroutines. Calling C subroutines can clobber any of them - the caller is responsible for saving and restoring.
  Call-saved registers (r2-r17, r28-r29):
  May be allocated by gcc for local data. Calling C subroutines leaves them unchanged. Assembler subroutines are responsible for saving and restoring these registers, if changed. r29:r28 (Y pointer) is used as a frame pointer (points to local data on stack) if necessary. The requirement for the callee to save/preserve the contents of these registers even applies in situations where the compiler assigns them for argument passing.
  Fixed registers (r0, r1):
  Never allocated by gcc for local data, but often used for fixed purposes: 
  
  r0 - temporary register, can be clobbered by any C code (except interrupt handlers which save it), may be used to remember something for a while within one piece of assembler code
  
  r1 - assumed to be always zero in any C code, may be used to remember something for a while within one piece of assembler code, but must then be cleared after use (clr r1). This includes any use of the [f]mul[s[u]] instructions, which return their result in r1:r0. Interrupt handlers save and clear r1 on entry, and restore r1 on exit (in case it was non-zero).
  Function call conventions:
  Arguments - allocated left to right, r25 to r8. All arguments are aligned to start in even-numbered registers (odd-sized arguments, including char, have one free register above them). This allows making better use of the movw instruction on the enhanced core. 
  
  
  If too many, those that don't fit are passed on the stack.
  
  Return values: 8-bit in r24 (not r25!), 16-bit in r25:r24, up to 32 bits in r22-r25, up to 64 bits in r18-r25. 8-bit return values are zero/sign-extended to 16 bits by the called function (unsigned char is more efficient than signed char - just clr r25). Arguments to functions with variable argument lists (printf etc.) are all passed on stack, and char is extended to int. 


http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_ramoverlap


  How to detect RAM memory and variable overlap problems?
  You can simply run avr-nm on your output (ELF) file. Run it with the -n option, and it will sort the symbols numerically (by default, they are sorted alphabetically).
  
  Look for the symbol _end, that's the first address in RAM that is not allocated by a variable. (avr-gcc internally adds 0x800000 to all data/bss variable addresses, so please ignore this offset.) Then, the run-time initialization code initializes the stack pointer (by default) to point to the last available address in (internal) SRAM. Thus, the region between _end and the end of SRAM is what is available for stack. (If your application uses malloc(), which e. g. also can happen inside printf(), the heap for dynamic memory is also located there. See Memory Areas and Using malloc().)
  
  The amount of stack required for your application cannot be determined that easily. For example, if you recursively call a function and forget to break that recursion, the amount of stack required is infinite. :-) You can look at the generated assembler code (avr-gcc ... -S), there's a comment in each generated assembler file that tells you the frame size for each generated function. That's the amount of stack required for this function, you have to add up that for all functions where you know that the calls could be nested.