TempDB (as with any other files) should be sized to a stable amount appropriate to your instance so that it shouldn't have to grow. The idea is to minimize autogrowth events, because any time your files have to grow, your queries will be forced to wait until the file growth has been completed. My practice(and this is my practice, your miles may vary) for sizing TempDB is as follows:
- Total TempDB data file size should be approximately 1/3rd my total data file size for all databases
- Number of data files is half the number of logical cores up to 8 total data files.
- Log file is sized to 1/3rd total size of TempDB data files
- I place TempDB on a LUN where it will have some space to grow, so that TempDB will have some ability to grow if a process requires more TempDB than I allocated.
- I set explicit values for TempDB file growth, typically 1GB (depends on file size). I do not use percentages for growth on any files, as percentage growth is harder to predict and accommodate.
As for giving space back to the OS, I typically don't do this. The only time I will give space back is if there was an obvious run away process that blew TempDB out to an abnormal size. To give the space back, I restart SQL in order to recreate TempDB fresh (as TempDB is created fresh on every SQL Service start) since shrinking TempDB can cause corruption.
There is a lot of discussion and opinion on exactly how TempDB should be configured. Again, this is my approach. For more on TempDB best practices and approaches, I recommend this whitepaper from Robert Davis(it's a vendor site, so you'll have to register).