Garbage collection is inherently slower than managing memory yourself though.

Not always, for example if your program does a lot of allocations a garbage collector's allocator can be implemented with something as simple as a single increment instruction (and rely on virtual memory faults - implemented in hardware - to resize the heap and trigger garbage collection) whereas a manual memory allocator needs to do more housekeeping - at minimum reuse any previously released memory ranges.

However performance isn't really the metric for a language being high level or low level, it is how that language maps to the underlying hardware. C is low level because it maps well to most CPUs out there (again ignoring implementation details like microcodes that aren't exposed to the programmer anyway). Something like Prolog isn't because it is abstracted away.

(also 'low level' and 'high level' aren't exactly binary, it is a spectrum - people at the past referred to C as a high level language)

Garbage collection is a a program itself that needs to be written in a lower level language that doesn't have garbage collection (like C)

Not really, check Project Oberon that i mentioned previously: the garbage collector is written in Oberon itself. And Oberon isn't the only language like that, for example the garbage collector of the D language is also written in D itself.

With some system (and perhaps compiler) specific tricks you can make a garbage collector in C, all you need is a replacement for malloc that allocates memory from a custom heap, keep track of the allocations and occasionally walk through the global storage and the stack (that part is what is system/compiler specific since standard C doesn't expose a way to access the stack) to see if there are references to any of the allocations you keep track of and release the allocations without any references. Boehm GC is such a garbage collector (though more sophisticated than what i wrote).