Skip to main content
added 2140 characters in body
Source Link
jksoegaard
  • 79.6k
  • 4
  • 133
  • 204

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kernel extension has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.

UPDATE: You have updated your question to ask a completely different question - namely "How to debug what threads take the most of the memory?".

This seems to indicate to me that this is a X/Y-question - you probably have some root issue you want to solve, and somehow you've come down a path where it makes sense for you to ask this question. However, the question doesn't really make much sense in technical terms, so it is difficult to actually help you without details on the actual problem you're trying to solve.

Technically, you cannot in general separate memory usage for each thread in a task like you want to do here. The very definition of threads (in this case, and almost always in other cases) is that they share memory with other threads. Therefore several threads inside a task could be using the same memory - and one thread can allocate memory that is used by a second thread that is eventually deallocated by a third thread. There exists a special class of memory named "thread local storage" which is really separate for each thread, but this construct is not commonly used in the macOS kernel (or in kernels in general).

Obviously you could instrument the kernel to log each allocation of memory and noting which thread did the allocation - but it wouldn't allow you to directly conclude that any "bug" is actually in that thread or anything like that.

By reading your question and various comments, you original problem sounds like you think your system is using too much memory, and you think a kernel extension is the culprit, but you do not know which one. These assumptions might be wrong (also on your part, as it is very common for non-technical people to have wrong assumptions on how memory allocation in computers actually work today).

In any case, I think the tool you might be looking for is simply zprint. Start Terminal.app and run:

sudo zprint -s -t 

This will print the total size of allocations created in each zone sorted by the sum.

This won't tell you which thread uses the most memory (obviously), but it is probably the values you're actually looking for.

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kernel extension has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kernel extension has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.

UPDATE: You have updated your question to ask a completely different question - namely "How to debug what threads take the most of the memory?".

This seems to indicate to me that this is a X/Y-question - you probably have some root issue you want to solve, and somehow you've come down a path where it makes sense for you to ask this question. However, the question doesn't really make much sense in technical terms, so it is difficult to actually help you without details on the actual problem you're trying to solve.

Technically, you cannot in general separate memory usage for each thread in a task like you want to do here. The very definition of threads (in this case, and almost always in other cases) is that they share memory with other threads. Therefore several threads inside a task could be using the same memory - and one thread can allocate memory that is used by a second thread that is eventually deallocated by a third thread. There exists a special class of memory named "thread local storage" which is really separate for each thread, but this construct is not commonly used in the macOS kernel (or in kernels in general).

Obviously you could instrument the kernel to log each allocation of memory and noting which thread did the allocation - but it wouldn't allow you to directly conclude that any "bug" is actually in that thread or anything like that.

By reading your question and various comments, you original problem sounds like you think your system is using too much memory, and you think a kernel extension is the culprit, but you do not know which one. These assumptions might be wrong (also on your part, as it is very common for non-technical people to have wrong assumptions on how memory allocation in computers actually work today).

In any case, I think the tool you might be looking for is simply zprint. Start Terminal.app and run:

sudo zprint -s -t 

This will print the total size of allocations created in each zone sorted by the sum.

This won't tell you which thread uses the most memory (obviously), but it is probably the values you're actually looking for.

added 8 characters in body
Source Link
jksoegaard
  • 79.6k
  • 4
  • 133
  • 204

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kextstatkernel extension has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kextstat has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kernel extension has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.

Source Link
jksoegaard
  • 79.6k
  • 4
  • 133
  • 204

There's a difference between the two as they are two completely different things. It would not make sense to compare them or expect that they should be equal.

The Size column in your kextstat output shows much memory the kernel extension itself takes up in memory. This is the amount of the memory that the code/data in the kernel extension itself takes up (i.e. comparable to the binary file size of the kernel extension). It doesn't have anything to do with how much memory the kextstat has used. Kernel extensions can dynamically allocate memory while running, and it doesn't show up in the Size column here, as it is a different thing.

The kernel_task memory usage shown is htop shows the actual memory usage of the kernel - this includes dynamically allocated memory. It can include memory used for the kernel itself, kernel extensions or memory allocated by the kernel on behalf of applications.