mjhjmtu

As I understand, the default stack size for a pthread on Linux is 16K. I am getting strange results on my 64-bit Ubuntu install.

$ ulimit -s
8192

Also:

pthread_attr_init(&attr);
pthread_attr_getstacksize(&attr, &stacksize);
printf("Thread stack size = %d bytes n", stacksize);

Prints
 Thread stack size = 8388608 bytes

I'm quite sure the stack size is not "8388608". What could be wrong?

int pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize);

The stacksize attribute shall define the minimum stack size (in
bytes) allocated for the created threads stack.

In your example, the stack size is set to 8388608 bytes which corresponds to 8MB, as returned by the command ulimit -s
So that matches.

From the pthread_create() description:

On Linux/x86-32, the default stack size for a new thread is 2
megabytes. Under the NPTL threading implementation, if the
RLIMIT_STACK soft resource limit at the time the program started has
any value other than "unlimited", then it determines the default
stack size of new threads. Using pthread_attr_setstacksize(3), the
stack size attribute can be explicitly set in the attr argument used
to create a thread, in order to obtain a stack size other than the
default.

So the thread stack size can be set either via the set function above, or the ulimit system property.
For the 16k you're referring to, it's not clear on which platform you've seen that and/or if any system limit was set for this.

See the pthread_create page and here for some interesting examples on this.

Actually, your virtual stack size is 8388608 bytes (8 MB). Of course, it's natural to conclude that this can't be right, because that's a ridiculously large amount of memory for every thread to consume for its stack when 99% of the time a couple of KB is probably all they need.

The good news is that your thread only uses the amount of physical memory that it actually needs. This is one of the magical powers that your OS gets from using the hardware Memory Management Unit (MMU) in your processor. Here's what happens:

1. The OS allocates 8 MB of virtual memory for your stack by setting up the MMU's page tables for your thread. This requires very little RAM to hold the page table entries only.




2. When your thread runs and tries to access a virtual address on the stack that doesn't have a physical page assigned to it yet, a hardware exception called a "page fault" is triggered by the MMU.




3. The CPU core responds to the page fault exception by switching to a privileged execution mode (which has its own stack) and calling the page fault exception handler function inside the kernel.




4. The kernel allocates a page of physical RAM to that virtual memory page and returns back to the user space thread.

The user space thread sees none of that work. From its point of view, it just uses the stack as if the memory was there all along. Meanwhile, the stack automatically grows (or doesn't) to meet the thread's needs.

The MMU is a key part of the hardware of today's computer systems. In particular, it's responsible for a lot of the "magic" in the system, so I highly recommend learning more about what the MMU does, and about virtual memory in general. Also, if your application is performance sensitive and deals with a significant amount of data, you should understand how the TLB (the MMU's page table cache) works and how you can restructure your data or your algorithms to maximize your TLB hit rate.